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I. 


INTRODUCTION 


A.  BACKGROUND  AND  MOTIVATION 

1.  Growth  of  Mobile  Computing 

The  explosive  growth  of  the  Internet  has  triggered  an  increased  reliance  on 
network  computing.  Most  organizations  today  have  sophisticated  networks  that  are 
connected  to  the  Internet.  The  major  benefit  reaped  from  such  a  networked  environment 
is  the  ability  for  an  employee  to  virtually  work  from  anywhere  at  any  time.  This  in  turn 
had  led  to  a  steady  rise  in  the  number  of  telecommuters  and  the  mobile  workforce. 
Coupled  with  the  increase  in  the  number  of  mobile  users  is  the  evolution  of  mobile 
device  technology  such  as  notebook  computers,  personal  digital  assistants  and  cell 
phones  to  facilitate  mobility.  The  combination  of  these  three  forces  -  increased  reliance 
on  network  computing,  a  growing  mobile  workforce,  and  the  evolution  in  mobile  device 
technology  -  drives  the  need  for  mobile  computers  to  communicate  seamlessly  with  other 
computers,  be  they  fixed  or  mobile. 

2.  Problems  Introduced  by  Mobility 

Internet  routing  plays  an  important  role  for  the  delivery  of  an  Internet  Protocol 
(IP)  packet  from  a  source  to  its  destination.  The  Internet  Protocol  standard  specified  in 
Request  For  Comments  (RFC)  791  [1]  describes  routing  of  IP  packets  to  be  based  upon 
destination  address.  By  consulting  its  routing  table,  each  network  node  is  able  to  make 
forwarding  decisions  based  only  upon  the  destination  address  field  within  the  IP  packet 
header.  For  maintainability  and  scalability  reasons,  routing  decisions  are  typically  made 
based  upon  the  network-prefix  of  the  IP  destination  address,  rather  than  the  entire  host- 
specific  IP  address.  Every  host  on  the  same  IP  network  would  have  an  identical  network- 
prefix.  When  a  node  moves,  it  will  have  to  change  its  network-prefix  (i.e.  IP  address)  to 
reflect  its  new  network  of  residence  to  the  routing  infrastructure  in  order  to  ensure 
continued  packet  delivery  service  with  other  networked  nodes. 

The  Transmission  Control  Protocol  (TCP),  specified  in  RFC  793  [2]  and  User 
Datagram  Protocol  (UDP),  specified  in  RFC  768  [3]  are  two  widely  used  transport  layer 
protocols  employed  in  the  operation  of  the  Internet.  TCP  is  a  connection-oriented 
protocol  providing  reliable  data  communications  to  higher  application  layers.  TCP  uses 

1 


port  identifiers  to  identify  the  separate  data/application  streams  that  it  may  handle.  A  TCP 
socket  is  uniquely  identified  by  the  concatenation  of  its  IP  address  with  the  TCP  port 
identifier,  and  a  TCP  connection  is  uniquely  identified  by  the  pair  of  sockets  at  both  ends. 
A  TCP  connection  will  drop  if  any  one  of  the  four  parameters,  namely,  source  IP  address, 
source  port,  destination  IP  address  and  destination  port,  were  to  change.  Thus,  any 
ongoing  communications  initiated  by  a  mobile  mode  would  be  terminated  and  have  to  be 
re-established  were  it  to  change  its  IP  address. 

It  is  apparent  from  the  foregoing  that  the  desired  functionality  of  mobility  presents 
two  conflicting  requirements.  The  mobile  node’s  IP  address  needs  to  change  according  to 
the  node’s  point-of-attachment  to  facilitate  continued  packet  delivery;  yet  existing 
connections  require  a  mobile  mode  to  retain  its  original  IP  address  for  session  continuity. 

3.  Mobility  Explained 

The  term  mobility  is  often  used  synonymously  with  nomadicity.  For  the  purpose 
of  clarifying  the  benefits  brought  about  by  Mobile  IP  as  specified  in  RFC  3344  [4],  it  is 
important  to  distinguish  between  the  two.  According  to  [5],  nomadicity  refers  to  the 
ability  of  users  moving  from  one  location  to  another  and  initiating  communications.  Such 
movement,  however,  would  require  a  user  to  terminate  and  restart  sessions  and 
applications  as  a  result  of  the  move.  Users  are  thus  responsible  for  establishing  a  new 
connection  wherever  they  go.  Mobility,  on  the  other  hand,  does  not  require  the  user  to 
terminate  and  re-initiate  a  connection  in  order  to  move  from  one  location  to  another.  All 
connections  are  automatically  maintained  despite  the  change  in  location.  The  relocation 
from  one  network  to  another  takes  place  without  any  user  intervention.  In  this  thesis,  the 
term  “roam”  will  be  used  synonymously  with  the  notion  of  mobility  presented  above. 

4.  Issues  with  Mobile  IP 

Despite  the  benefits  brought  about  by  Mobile  IP,  there  are  some  technical 
challenges  introduced  by  Mobile  IP  that  need  to  be  overcome  before  it  is  deemed  worthy 
of  widespread  adoption.  Two  of  the  dominant  technical  challenges  are  identified  and 
briefly  described  next,  which  serve  to  set  the  stage  for  the  purpose  of  this  research. 
a.  TCP  Performance 

As  described  in  [6],  the  TCP  congestion  control  mechanism  interprets  the 
cause  of  the  majority  of  lost  segments  and  acknowledgments  to  be  the  result  of 
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congestion.  This  assumption  is  valid  for  most  of  the  operational  Internet,  but  does  not 
necessarily  hold  true  for  the  mobile  environment,  where  lost  segments  and 
acknowledgments  can  be  expected  to  occur  due  to  the  required  handoff  protocol  traffic 
and  processing  taking  place  when  a  mobile  node  roams.  Moreover,  transmission  over  the 
error-prone  radio-frequency  medium  in  a  wireless  mobile  environment  is  the  likely  cause 
for  majority  of  the  lost  packets  and  acknowledgments.  The  combination  of  these  two 
factors  -  mobility  and  the  wireless  environment  over  which  mobile  nodes  communicate  - 
can  severely  degrade  the  performance  of  TCP. 

b.  Security 

The  mode  of  operations  in  a  mobile  computing  environment  differs  from 
that  of  an  ordinary  computing  environment.  In  most  scenarios,  mobile  nodes  are 
connected  via  wireless  means,  which  are  particularly  susceptible  to  active  and  passive 
attacks.  Moreover,  the  ability  for  a  mobile  node  to  roam  to  virtually  anywhere  on  the 
Internet  introduces  unprecedented  risks,  in  which  IP  packets  meant  for  the  mobile  node 
could  potentially  be  subjected  to  Denial-of-Service  (DoS)  and  traffic  redirection  attacks  if 
the  Mobile  IP  registration  process  was  not  authenticated. 


B.  RESEARCH  METHODOLOGY  AND  ORGANIZATION 

1.  Primary  Research  Question 

•  Will  the  Mobile  IP  protocol  described  in  RFC  3344  (and  related 
RFCs)  provide  sufficiently  quick  and  sufficiently  reliable  handoffs 
to  support  the  relatively  rapid  roaming  of  connected  wireless 
(IEEE  802. 11)  hosts? 

2.  Subsidiary  Research  Questions 

•  What  is  the  goal  of  Mobile  IP? 

•  What  constitutes  a  Mobile  IP  handoff? 

•  What  are  the  constituent  functional  components  underlying  the 
Mobile  IP  protocol  that  facilitates  the  roaming  of  the  mobile  host? 

•  What  is  the  basic  protocol  functionality  used  by  IEEE  802.11  to 
associate  and  disassociate  wireless  hosts? 
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•  How  would  a  test  lab  network  be  architected  and  instrumented  so 
as  to  best  measure  time/performance  statistics  for  each  of  the 
constituent  functional  components? 

•  What  are  the  test  cases  that  should  be  employed  to  generate  the 
data  that  will  be  used  for  performance  analysis? 

•  Which  of  the  protocol’s  constituent  parts  are  good  candidates  for 
test  data  collection? 

•  Does  the  collected  data  provide  any  insights  regarding  how  the 
mobile  handoff  of  wireless  (IEEE  802.11)  clients  may  be  done 
more  quickly?  If  so,  what  are  they  and  how  should  they  be 
adjusted  for  quicker,  more  seamless,  handoffs? 

•  Does  the  collected  data  provide  any  insights  regarding  how  the 
mobile  handoff  of  wireless  (IEEE  802.11)  clients  might  be 
vulnerable  to  DoS  or  traffic  redirection  type  attacks? 


3.  Assumptions 

The  operation  of  the  Mobile  IP  protocol  is  built  upon  the  basics  of  computer 

networking  and  IP  routing.  This  thesis  report  assumes  that  the  reader  has  the  necessary 
background  to  understand  the  contents  presented  herein.  It  is  not  the  intent  of  this  thesis 
report  to  describe  computer  networking  and  IP  routing  at  length.  Readers  can  refer  to  [7] 
and  [8]  for  a  more  thorough  treatment  of  the  topic. 

4.  Scope 

Mobile  IP  defines  the  mechanisms  and  protocol  behaviors  necessary  to  facilitate 

the  seamless  flow  of  traffic  to  a  mobile  host  that  roams  from  its  normal  home  network. 
Of  particular  interest  in  this  research,  is  how  this  capability  might  support  the  relatively 
rapid  roaming  of  a  wirelessly  connected  host.  This  research  is  focused  on  isolating  and 
analyzing  the  constituent  components  of  the  Mobile  IP  protocol  for  the  purpose  of 
identifying  any  component(s)  that  may  be  improved  upon,  or  may  be  exploited  by  an 
attacker  intent  on  denying  or  delaying  proper  handoff  service. 

The  scope  of  this  research  involves  setting  up  a  controlled  environment  to 
demonstrate  the  operations  of  Mobile  IP  version  4  to  support  the  roaming  of  a  wirelessly 
connected  host.  The  setup  shall  be  configured  based  on  existing  Cisco  hardware  and 
software  available  within  the  campus.  Performance  statistics  for  the  constituent 
functional  components  that  facilitate  the  roaming  of  the  mobile  host  shall  be  collected 
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and  analyzed  for  the  performance  and  security  ramifications  associated  with  the  mobile 
handoff  of  wireless  (IEEE  802.11)  clients. 

5.  Chapter  and  Appendix  Overview 

This  thesis  is  comprised  of  the  following  chapters  and  appendices: 

Chapter  I:  Introduction  -  This  chapter  introduces  the  driving  factor  for  mobility 
and  recognizes  the  need  for  Mobile  IP  to  support  mobility.  Issues  concerned  with  Mobile 
IP  are  briefly  described  to  set  the  stage  for  the  focus  of  this  research. 

Chapter  II:  Operations  of  Mobile  IP  Version  4  -  This  chapter  discusses  the 
salient  points  of  RFC  3344  [4]  and  presents  the  essential  functional  components  in  order 
to  facilitate  the  performance  measurements  and  analysis  identified  in  this  research. 

Chapter  III:  IEEE  802.11  Protocol  Primer  -  This  chapter  outlines  the  basic 
operation  for  the  IEEE  802.11  wireless  environment  in  an  infrastructure  mode,  used  in 
the  instrumented  lab  setup  in  this  research. 

Chapter  IV:  Setting  Up  the  Mobile  IP  Test  Environment  -  This  chapter 
describes  the  topological  design  and  architecture,  considerations,  test  plan,  data  collection 
and  collation  strategy  for  collecting  and  analyzing  the  performance  statistics. 

Chapter  V:  Results  and  Findings  -  This  chapter  presents  the  performance 
statistics  for  the  Mobile  IP  handoff  components,  analyzes  the  results  and  identifies 
potential  candidates  for  performance  fine-tuning.  The  chapter  discusses  the  types  of 
applications  that  can  be  supported  by  Mobile  IP,  and  concludes  with  a  brief  discussion  on 
the  security  ramifications  associated  with  Mobile  IP. 

Chapter  VI:  Conclusions  -  This  chapter  summarizes  the  conclusion,  discusses 
the  major  challenges  and  recommends  potential  areas  for  future  research. 

Appendix  A:  Configuration  Setup  -  This  section  documents  the  configuration 
details  of  the  respective  components  for  the  Mobile  IP  test  environment  identified  in 
Chapter  IV. 

Appendix  B:  Test  Results  -  This  section  includes  the  detailed  test  results  that 
were  collected  and  collated  by  conducting  the  respective  test  cases  identified  in  Chapter 
IV. 
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II.  OPERATIONS  OF  MOBILE  IP  VERSION  4 


A.  INTRODUCTION 

The  Mobile  IP  protocol  was  originally  defined  as  a  standard  in  RFC  2002  [9]  by 
the  Internet  Engineering  Task  Force  (IETF)  in  October  1996.  Since  then,  a  number  of 
additional  RFCs  have  proposed  enhanced  functionality  and  clarified  the  original 
standards.  The  core  Mobile  IP  protocol  has  been  updated  and  is  currently  defined  in  RFC 
3344  [4],  RFC  3344  serves  as  the  main  source  of  reference  for  the  concepts  described  in 
this  chapter,  with  additional  references  taken  from  [5],  [6]  and  [10]  to  provide  appropriate 
clarifications  and  illustrations. 

This  chapter  will  describe  the  constituent  functional  components  underlying  the 
Mobile  IP  protocol,  namely,  Agent  Discovery,  Registration  and  Routing.  Having 
understood  the  functional  components,  it  will  be  appropriate  to  explain  what  constitutes  a 
Mobile  IP  handoff.  The  chapter  then  concludes  by  presenting  the  security  considerations, 
as  well  as  how  the  Mobile  IP  protocol  addresses  some  of  these  issues. 

1.  Goals  and  Assumptions 

The  Mobile  IP  protocol  was  designed  to  meet  the  following  goals: 

•  A  mobile  node  must  be  able  to  communicate  with  other  nodes  after 
changing  its  physical  point-of-attachment  to  the  Internet  without  changing 
its  IP  address. 

•  A  mobile  node  must  be  able  to  communicate  with  other  nodes  that  do  not 
implement  the  Mobile  IP  functionality. 

•  Introduction  of  the  Mobile  IP  protocol  must  not  expose  the  mobile  node  to 
any  new  security  threats  over  and  above  those  current  threats  faced  by 
fixed  nodes  that  are  connected  to  the  Internet. 

•  Due  to  the  resource  constraints  imposed  on  a  mobile  node,  administrative 
messages  sent  over  the  physical  link  by  which  a  mobile  node  is  directly 
attached  to  the  Internet  should  be  kept  minimal  in  size  and  number. 

The  developers  of  the  Mobile  IP  protocol  also  made  two  fundamental 
assumptions,  namely 

•  Mobile  nodes  will  generally  not  change  their  physical  point-of-attachment 
more  frequently  than  once  per  second; 
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•  Routing  of  IP  unicast  packets  is  based  only  upon  the  destination  address 

field  within  the  IP  packet  header. 

2.  New  Architectural  Entities  and  Terminology 

Mobile  IP  defines  three  new  architectural  entities  that  are  used  to  implement  its 
mobility  functionality.  The  relationships  among  these  architectural  entities  are  illustrated 
in  Figure  1 . 

a.  Mobile  Node 

A  mobile  node  can  either  be  a  host  or  a  router  that  changes  its  physical 
point-of-attachment  to  the  Internet  without  changing  its  IP  address,  yet  maintaining  any 
ongoing  communications  with  other  nodes  on  the  Internet  using  its  constant  IP  address. 

b.  Home  Agent 

A  router  on  a  mobile  node’s  home  network  that  maintains  up-to-date 
location  information  about  the  mobile  node  and  tunnels  IP  packets  for  delivery  to  the 
mobile  node  when  it  is  away  from  its  home  network. 

c.  Foreign  Agent 

A  router  on  a  mobile  node’s  visited  network  that  provides  Mobile  IP 
services  to  the  mobile  node  while  it  is  registered.  The  foreign  agent  is  capable  of  offering 
one  or  more  of  its  IP  addresses  as  a  care-of  address;  in  which  case  the  foreign  agent  will 
serve  to  de-tunnel  and  deliver  IP  packets  to  the  mobile  node  that  were  tunneled  by  the 
mobile  node’s  home  agent.  The  foreign  agent  may  assist  the  mobile  node  in  informing  its 
home  agent  of  its  current  care-of  address;  and  may  serve  as  a  default  router  for  routing 
traffic  from  the  registered  mobile  node. 

Besides  identifying  the  functional  entities,  the  following  terminology  is 
commonly  used  to  describe  the  concepts  underlying  the  operations  of  Mobile  IP. 

d.  Authentication  Extension 

An  authentication  extension  is  appended  to  the  end  of  a  registration 
message  that  contains  relevant  security  information  to  authenticate  and  protect  the 
integrity  of  the  registration  process.  The  concept  of  the  authentication  extension  will  be 
described  in  detail  under  the  Security  Considerations  of  this  chapter. 
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e.  Authorization-enabling  Extension 

An  authorization-enabling  extension  refers  to  the  use  of  an  authentication 
extension  that  facilitates  the  acceptance  of  a  registration  request  or  reply  message  by  the 
recipient  of  the  message. 

f.  Care-of Address 

A  care-of  address  signifies  the  termination  point  of  a  tunnel  established  by 
a  mobile  node’s  home  agent,  for  IP  packets  to  be  forwarded  to  the  mobile  node  when  it  is 
away  from  its  home  network.  The  Mobile  IP  protocol  uses  two  different  types  of  care-of 
address:  a  foreign  agent  care-of  address  is  an  IP  address  of  a  foreign  agent  with  which  the 
mobile  node  is  registered;  a  co-located  care-of  address  is  an  externally  obtained  local  IP 
address  from  the  mobile  node’s  current  point-of-attachment. 

g.  Correspondent  Node 

A  correspondent  node  is  a  peer  node  with  which  a  mobile  node  is 
currently  communicating.  A  correspondent  node  can  either  be  a  fixed  or  mobile  node. 

h.  Foreign  Network 

A  foreign  network  is  any  network  other  than  the  mobile  node’s  home 

network. 

i.  Home  Address 

A  home  address  is  an  IP  address  that  is  assigned  to  the  mobile  node  either 
statically  by  a  network  administrator,  or  dynamically  via  the  Dynamic  Host 
Configuration  Protocol  (DHCP)  [11]  for  some  configurable  leased  period.  This  address 
remains  constant  when  the  mobile  node  changes  its  point-of-attachment  to  the  Internet. 

j.  Home  Network 

A  home  network  has  a  network-prefix  that  matches  the  mobile  node’s 
home  address.  IP  packets  destined  for  the  mobile  node  will  be  routed  to  the  mobile 
node’s  home  network  for  delivery  to  the  mobile  node. 

k.  Mobility  Agent 

A  mobility  agent  refers  to  either  a  home  agent  or  a  foreign  agent. 
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1.  Mobility  Binding 

A  mobility  binding  refers  to  the  association  of  a  mobile  node’s  home 
address  with  a  care-of  address,  along  with  the  remaining  lifetime  of  that  association. 
Mobility  bindings  are  maintained  at  the  mobile  node’s  home  agent. 

in.  Mobility  Security  Association 

A  mobility  security  association  refers  to  a  collection  of  security  contexts 
that  exist  between  a  pair  of  nodes,  which  may  be  applied  to  Mobile  IP  protocol  messages 
that  are  exchanged  between  them.  The  concept  of  the  mobility  security  association  will 
be  described  in  detail  under  the  Security  Considerations  of  this  chapter. 

n.  Tunnel 

A  tunnel  is  the  path  followed  by  an  IP  packet  while  it  is  encapsulated.  A 
tunnel  is  established  between  the  mobile  node’s  home  agent  and  the  mobile  node’s  care- 
of  address.  IP  packets  destined  for  the  mobile  node  will  be  encapsulated  by  the  home 
agent  upon  entering  this  tunnel,  and  decapsulated  by  the  tunnel  end-point  for  correct 
delivery  to  the  mobile  node.  The  concept  of  tunneling  will  be  described  in  detail  under 
the  Routing  section  of  this  chapter. 

o.  Visited  Network 

A  visited  network  is  a  foreign  network  to  which  the  mobile  node  is 
currently  attached. 

p.  Visitor  List 

A  visitor  list  refers  to  the  list  of  mobile  nodes  visiting  a  foreign  network, 
and  is  maintained  by  the  foreign  agent  serving  that  foreign  network. 

Figure  1  illustrates  the  relationships  among  the  architectural  entities  and  the 
corresponding  Mobile  IP  terminology. 
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Mobile  Node  visiting  a  foreign  network 


Figure  1.  Mobile  IP  Entities  and  Relationships  (After:  [5]  &  [6]). 
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3.  Protocol  Overview 

An  overview  of  the  operation  of  the  Mobile  IP  protocol  is  described  in  Figure  2. 
Details  of  each  component  will  be  explored  in  greater  detail  in  the  subsequent  sections. 
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Figure  2.  Overview  of  Mobile  IP  Operation. 
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B.  AGENT  DISCOVERY 

Agent  discovery  is  the  process  by  which  a  mobile  node  determines  whether  it  is 
currently  connected  to  its  home  network  or  to  a  foreign  network,  thereby  allowing  the 
mobile  node  to  detect  if  it  has  moved  from  one  network  to  another.  In  the  case  where  the 
mobile  node  has  moved  to  a  foreign  network,  the  process  of  agent  discovery  will  also 
facilitate  its  obtainment  of  a  care-of  address. 

1.  Agent  Advertisement 

Agent  advertisements  are  periodically  transmitted  by  home  agents  and  foreign 
agents  to  advertise  their  offered  Mobile  IP  services  on  a  network.  Mobile  nodes  make  use 
of  these  advertisements  to  determine  their  current  or  possibly  new  point-of-attachment  to 
the  Internet.  An  agent  advertisement  message  is  in  fact  an  Internet  Control  Message 
Protocol  (ICMP)  [12]  router  advertisement  [13]  that  has  been  extended  to  carry  a 
mobility  agent  advertisement  extension  and  other  optional  extensions.  Figure  3  shows 
such  an  agent  advertisement  message,  with  Table  1  describing  its  corresponding  fields. 


IP  Header 
[RFC  791] 


ICMP  Router 
Advertisement 
[RFC  1256] 


Mobility  Agent 
Advertisement 
Extension 
[RFC  3344] 


[RFC  3344] 


Figure  3.  Agent  Advertisement  Message  (After:  [4]  &  [6]). 


0123456789 
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0  1 


23456789012345678901 


Version  =  4 


IHL 


Type  of  Service 


Total  Length 


Identification 


Flags 


Fragment  Offset 


Time-to-Live  =  1 


Protocol  =  ICMP 


Header  Checksum 


Source  Address  =  Home  /  Foreign  agent's  IP  address 


Destination  Address  =  255.255.255.255  (broadcast)  or  224.0.0.1  (multicast) 


Type  =  9 


Code 


Checksum 


Num  Addrs 


Addr  Entry  Size 


Lifetime  (of  this  advertisement) 


Router  Address  [1] 


Preference  Level  [1] 


Router  Address  [2] 


Preference  Level  [2] 


Type  =  16 


Length 


Sequence  Number 


Registration  Lifetime 


R  B  H  F  M  G  r  T 


reserved 


zero  or  more  Care-of  Address(es) 


Other  optional  extensions 
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Field 

Description 

IP  Header 

Time-to-Live 

The  TTL  for  all  agent  advertisements  must  be  set  to  1 . 

ICMP  Header 

Type 

A  type  field  of  9  identifies  the  ICMP  message  as  an  adverstisement. 

Code 

Mobile  IP  home  agents  and  foreign  agents  use  the  value  of  16  to  prevent  any  nodes 
other  than  mobile  nodes  to  use  them  as  routers.  A  value  of  0  allows  nodes  on  the 
network  to  use  them  as  routers. 

Lifetime 

Indicates  how  frequently  this  agent  sends  advertisement.  The  lifetime  field  is  used 
primarily  for  move  detection. 

Num  Addrs 

Reflects  the  number  of  router  address  /  preference  level  pairs  that  are  listed  in  this 
advertisement,  and  the  corresponding  number  of  bytes  each  pair  occupies. 

Addr  Entry  Size 

Mobility  Agent  Advertisement  Extension 

Type 

A  type  field  of  16  identifies  the  extension  as  a  mobility  agent  advertisement  extension. 

Length 

Gives  the  number  of  bytes  in  the  data  portion  of  the  extension,  which  is  equivalent  to  6  + 

4  *  number  of  care-of  addresses  advertised,  where  6  accounts  for  number  of  bytes  in  the 
Sequence  Number,  Registration  Lifetime,  flags  and  reserved  fields. 

Sequence 

Number 

The  count  of  agent  advertisement  messages  sent  since  the  agent  was  last  initiated.  An 
agent  must  use  the  number  0  for  its  first  advertisement  after  booting.  Each  subsequent 
advertisement  must  use  the  sequence  number  that  is  one  greater  than  the  previous,  with 
the  exception  that  the  sequence  number  Oxffff  must  be  followed  by  sequence  number 

256  to  indicate  a  rollover  in  sequence  number. 

Registration 

Lifetime 

The  longest  lifetime  (measured  in  seconds)  that  this  agent  is  willing  to  accept  in  any 
registration  request.  This  field  has  no  relation  to  the  Lifetime  field  within  the  ICMP  router 
advertisement  portion  of  the  agent  advertisement. 

R 

Registration  required.  Registration  with  this  foreign  agent  is  required  even  when  a  co¬ 
located  care-of  address  is  used.  An  agent  advertisement  must  not  have  the  'R'  bit  set  if 
the  'F'  bit  is  not  set. 

B 

Busy.  The  foreign  agent  will  not  accept  registrations  from  additional  mobile  nodes.  An 
agent  advertisement  must  not  have  the  'B'  bit  set  if  the  'F'  bit  is  not  set. 

H 

Home  agent.  This  agent  offers  service  as  a  home  agent  on  the  network  where  this  agent 
advertisement  is  sent. 

F 

Foreign  agent.  This  agent  offers  service  as  a  foreign  agent  on  the  network  where  this 
agent  advertisement  is  sent. 

M 

Minimal  encapsulation.  This  agent  supports  receiving  tunneled  IP  packets  that  use 
minimal  encapsulation  [14]. 

G 

GRE  encapsulation.  This  agent  supports  receiving  tunneled  IP  packets  that  use  GRE 
encapsulation  [15]. 

r 

Set  as  zero;  ignored  on  reception. 

T 

Foreign  agent  supports  reverse  tunneling  [16]. 

reserved 

Set  as  zero;  ignored  on  reception. 

Care-of 

Address  (es) 

The  advertised  foreign  agent  care-of  address(es)  provided  by  this  foreign  agent.  An 
agent  advertisement  must  include  at  least  one  care-of  address  if  the  'F'  bit  is  set. 

Other  Optional  Extensions 

- 

Other  optional  extensions  include  the  prefix-length  extension  and  one-byte  padding 
extension. 

Table  1.  Agent  Advertisement  Message  Fields. 
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2.  Agent  Solicitation 

Agent  solicitations  are  sent  by  mobile  nodes  to  force  any  agents  on  the  network  to 
immediately  respond  with  an  agent  advertisement,  without  having  to  wait  for  the  next 
periodic  transmission  of  agent  advertisements.  An  agent  solicitation  message  is  identical 
to  the  ICMP  router  solicitation  message  [13]  with  the  restriction  that  the  IP  Time-To-Live 
(TTL)  field  must  be  set  to  one.  A  type  field  of  value  10  identifies  the  ICMP  message  as  a 
solicitation  message.  An  agent  solicitation  message  is  shown  in  Figure  4. 


IP  Header 
[RFC  791]  & 
Requirements 
in 

[RFC  3344] 


ICMP  Router 
Solicitation 
[RFC  1256] 


Figure  4.  Agent  Solicitation  Message  (After:  [4]  &  [6]). 


0  12  3 

01234567890123456789012345678901 


|  Version  =  4  IHL 

Type  of  Service 

Total  Length 

Identification 

Flags  Fragment  Offset 

Time-to-Live  =  1 

Protocol  =  ICMP 

Header  Checksum 

Source  Address  =  Mobile  Node's  Home  Address 

Destination  Address  =  255.255.255.255  (broadcast)  or  224.0.0.1 1  (multicast) 

Type  = 10 

Code  =  0 

Checksum  | 

reserved 

3.  Move  Detection 

Mobile  nodes  are  responsible  for  engaging  in  the  continuous  process  of  move 
detection,  which  is  the  act  of  monitoring  changes  in  available  paths  into  the  network  at 
large.  Two  primary  mechanisms  are  provided  for  mobile  nodes  to  detect  when  they  have 
moved  from  one  network  to  another. 

a.  Move  Detection  Using  Lifetime 

A  mobile  node  uses  the  lifetime  field  in  the  ICMP  header  of  an  agent 
advertisement  message  to  determine  if  it  has  moved.  Figure  5  illustrates  such  a  move 
detection  process  using  the  lifetime  field. 
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Figure  5.  Move  Detection  using  Lifetime. 


b.  Move  Detection  Using  Network  Prefix 

A  mobile  node  uses  the  network  address  based  on  the  network  prefixes 

specified  in  the  prefix-length  extension  of  an  agent  advertisement  message  to  determine  if 

a  newly  received  agent  advertisement  was  received  from  the  same  network  as  the  mobile 

node’s  current  care-of  address.  If  the  network  addresses  differ,  the  mobile  node  concludes 

that  it  has  moved  and  will  proceed  to  register  with  the  new  foreign  agent  that  sent  this 

agent  advertisement.  If  the  network  addresses  are  the  same,  the  mobile  node  concludes 

that  it  has  not  moved.  The  mobile  node  will  not  need  to  register  with  this  new  foreign 

agent  unless  it  has  not  received  an  advertisement  within  the  specified  lifetime  from  its 

currently  registered  foreign  agent.  Thus,  this  method  of  move  detection  still  relies  on  the 
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first  method  of  move  detection  using  lifetime  to  check  for  the  availability  of  the  mobile 
node’s  current  foreign  agent.  Moreover,  move  detection  using  a  network  prefix  can  only 
be  used  if  all  agent  advertisements  include  the  prefix-length  extensions  and  the  mobile 
node  knows  the  network  prefix  of  its  current  care-of  address  (for  the  case  of  co-located 
care-of  address).  Figure  6  illustrates  the  move  detection  mechanism  using  network  prefix. 


Figure  6.  Move  Detection  using  Network  Prefix. 
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C.  REGISTRATION 

Mobile  IP  registration  is  the  process  that  mobile  nodes  use  to  communicate  their 
current  reachability  information  to  their  home  agents,  so  that  IP  traffic  destined  for  the 
mobile  nodes  can  be  delivered  to  them  when  they  are  away  from  their  home  network.  A 
mobile  node  uses  the  registration  process  to: 

•  Request  forwarding  services  when  visiting  a  foreign  network; 

•  Inform  its  home  agent  of  its  current  care-of  address(es); 

•  Renew  a  registration  which  is  due  to  expire; 

•  De-register  when  it  returns  home. 

1.  Registration  Overview 

The  Mobile  IP  registration  process  comprises  mainly  the  exchange  of  two 
messages,  a  registration  request  and  a  registration  reply,  using  UDP  [3],  A  registration 
involves  an  exchange  of  a  registration  request  and  a  registration  reply  between  a  mobile 
node  and  its  home  agent.  Depending  on  the  registration  options  and  the  type  of  care-of 
address  used  by  the  mobile  node,  a  foreign  agent  may  be  involved  in  the  registration 
process.  Figures  7-10  depict  the  four  scenarios  under  which  registration  could  take 
place. 


Registration  Request  using 


1.  Mobile  node  sends  a  registration  request  using  foreign  agent’s  care-of  address  (obtained  from  agent 
advertisement)  to  foreign  agent. 

2.  Foreign  agent  processes  the  registration  request  and  relays  it  to  home  agent  (if  foreign  agent 
supports  requested  services). 

3.  Home  agent  sends  a  registration  reply  to  foreign  agent  to  grant  or  deny  the  request. 

4.  Foreign  agent  processes  the  registration  reply  and  relays  it  to  the  mobile  node. 

Figure  7.  Registration  using  Foreign  Agent’s  Care-of  Address  (After:  [4]  &  [6]). 
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Registration  Request  using 


1.  Mobile  node  sends  a  registration  request  using  co-located  care-of  address  to  foreign  agent  (agent 
advertisement  received  on  the  foreign  network  where  mobile  node  resides  has  “Registration  Required”  bit  set). 

2.  Foreign  agent  processes  the  registration  request  and  relays  it  to  home  agent  (if  foreign  agent  supports 
requested  services). 

3.  Home  agent  sends  a  registration  reply  to  foreign  agent  to  grant  or  deny  the  request. 

4.  Foreign  agent  processes  the  registration  reply  and  relays  it  to  the  mobile  node. 

Figure  8.  Registration  via  Foreign  Agent  using  Co-located  Care-of  Address 

(After:  [4]  &  [6]). 


1.  Registration  Request  using 
Mobile  Node  Co-located  Care-of  Address 


1 .  Mobile  node  sends  a  registration  request  using  co-located  care-of  address  to  the  home  agent. 

2.  Home  agent  sends  a  registration  reply  to  the  mobile  node,  granting  or  denying  the  request. 

Figure  9.  Direct  Registration  using  Co-located  Care-of  Address  (After:  [4]  &  [6]). 

Mobile  Node 


1 .  Mobile  node  detects  that  it  has  returned  to  its  home  network  and  sends  a  registration  request  to 
de-register  with  its  home  agent. 

2.  Home  agent  sends  a  registration  reply  to  the  mobile  node,  granting  or  denying  the  request. 

Figure  10.  De-registration  upon  Returning  Home  (After:  [4]  &  [6]). 


19 


2.  Registration  Request 

A  mobile  node  initiates  the  registration  process  by  sending  a  registration  request 
message.  A  mobile  node  registers  with  its  home  agent  so  that  its  home  agent  can  create  a 
mobility  binding  (when  the  mobile  node  relocates  to  another  network)  or  modify  an 
existing  mobility  binding  (when  the  mobile  node  renews  a  registration  which  is  about  to 
expire)  for  that  mobile  node.  Figure  11  shows  a  registration  request  message,  with  Table 
2  describing  its  corresponding  fields. 

0  12  3 

01234567890123456789012345678901 


IP  Header 
[RFC  791] 


UDP  Header 
[RFC  768] 


Fixed-Length 
Portion  of 
Registration 
Request 
[RFC  3344] 


[RFC  3344] 


Figure  11.  Registration  Request  Message  (After:  [4]  &  [6]). 


|  Version  =  4  IHL 

Type  of  Service 

Total  Length 

Identification 

Flags  Fragment  Offset 

Time-to-Live 

Protocol  =  UDP 

Header  Checksum 

Source  Address 

Destination  Address 

Source  Port  =  Variable 

Destination  Port  =  434 

Length 

Checksum 

Type  =  1 

Lifetime 

Mobile  Node's  Home  Address 

Home  Agent  Address 

Care-of  Address 

Identification 

I  Extensions...  I 

I  I 
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Field 

Description 

IP  Header 

Source 

Address 

Mobile  Node :  If  a  co-lcated  care-of  address  is  used,  IP  source  address  must  be  the  care-of  address.  If 
it  does  not  have  a  home  address,  IP  source  address  is  set  to  0.0. 0.0.  Otherwise,  IP  source  address 
must  be  its  home  address. 

Foreign  Agent :  Interface  address  from  which  the  request  is  forwarded  to  home  agent. 

Destination 

Address 

Mobile  Node:  1 .  If  it  has  discovered  the  agent  with  which  it  is  registering  through  other  means  where 
the  IP  address  is  unknown,  the  "All  Mobility  Agents"  multicast  address  of  224.0.0.11  must  be  used. 
Subsequent  request  is  then  sent  to  the  agent's  unicast  address.  2.  If  it  is  registering  with  a  foreign 
agent,  address  of  the  foreign  agent  (obtained  from  agent  advertisement)  must  be  used.  3.  If  it  is 
registering  directly  with  its  home  agent  and  knows  the  home  agent's  unicast  IP  address,  this  will  be 
used  as  destination  address.  Otherwise,  it  uses  dynamic  home  agent  address  resolution  to  determine 
the  IP  address  of  its  home  agent  by  setting  the  address  field  to  the  home  network's  subnet-directed 
broadcast. 

Foreign  Agent:  Copied  from  home  agent  field  within  the  received  registration  request. 

Time-to-Live 

IP  TTL  field  must  be  set  to  1  if  the  IP  destination  address  is  set  to  the  "All  Mobility  Agents"  multicast 
address. 

UDP  Header 

Source  Port 

Variable. 

Destination 

Port 

A  value  of  434  is  reserved  for  Mobile  IP  registration  messages. 

Fixed-Length  Portion  of  Registration  Request 


Type 

A  type  field  of  1  identifies  message  as  a  registration  request. 

s 

Simultaneous  bindings.  Mobile  node  is  requesting  that  the  home  agent  retains  its  prior  mobility 
bindings,  otherwise  home  agent  deletes  any  previous  bindings  and  replaces  with  new  binding  specified 
in  registration  request. 

B 

Broadcast  datagrams.  If  the  'B'  bit  is  set,  mobile  node  is  requesting  that  the  home  agent  tunnels  to  it 
any  broadcast  IP  packets  it  receives  on  the  home  network. 

D 

Decapsulation  by  mobile  node.  If  the  'D'  bit  is  set,  the  mobile  node  will  perform  its  own  decapsulation 
of  IP  packets  that  are  sent  to  the  care-of  address,  i.e.,  mobile  node  is  using  a  co-located  care-of 
address. 

M 

Minimal  encapsulation.  If  the  'M'  bit  is  set,  the  mobile  node  requests  that  its  home  agent  use  minimal 
encapsulation  [14]  for  IP  packets  tunneled  to  the  mobile  node. 

G 

GRE  encapsulation.  If  the  'G'  bit  is  set,  the  mobile  node  requests  that  its  home  agent  use  GRE 
encapsulation  [15]  for  IP  packets  tunneled  to  the  mobile  node. 

r 

Set  as  zero;  ignored  on  reception. 

T 

Mobile  node  is  requesting  for  reverse  tunneling  [16]  service. 

X 

Set  as  zero;  ignored  on  reception. 

Lifetime 

The  number  of  seconds  remaining  before  the  registration  is  considered  to  be  expired.  A  value  of  0 
indicates  a  request  for  deregistration. 

Home  Address 

IP  address  of  the  mobile  node  if  it  is  known,  otherwise  set  to  0.0. 0.0. 

Home  Agent 

IP  address  of  the  mobile  node's  home  agent  if  it  is  known,  otherwise  set  to  home  network's  subnet- 
directed  broadcast. 

Care-of 

Address 

IP  address  for  the  end  of  the  tunnel  established  by  the  home  agent,  set  to  value  of  particular  care-of 
address  that  mobile  node  wishes  to  (de)register.  This  value  is  set  to  mobile  node's  home  address  if  it 
wishes  to  de-register  all  care-of  addresses. 

Identification 

A  64-bit  number  that  is  constructed  by  the  mobile  node  for  matching  registration  requests  with 
registration  replies,  and  for  protecting  against  replay  attacks  of  registration  messages. 

Extensions 

The  fixed-length  portion  of  the  registration  request  is  followed  by  one  or  more  extensions  that  are 
described  in  the  subsequent  sections  of  this  chapter.  An  authorization-enabling  extension  must  be 
included  in  all  registration  requests. 

Table  2.  Registration  Request  Message  Fields. 
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3.  Registration  Reply 

A  registration  reply  is  generated  by  a  home  agent  or  foreign  agent  in  response  to  a 
registration  request  initiated  by  a  mobile  node.  A  registration  reply  message  contains  the 
necessary  codes  to  inform  the  mobile  node  about  the  status  of  its  request,  along  with  the 
lifetime  that  is  granted  by  the  home  agent,  which  may  be  smaller  than  the  requested 
lifetime.  Figure  12  shows  a  registration  reply  message,  with  Table  3  describing  its 
corresponding  fields. 

0  12  3 

01234567890123456789012345678901 


IP  Header 
[RFC  791] 


UDP  Header 
[RFC  768] 


Fixed-Length 
Portion  of 
Registration 
Reply 

[RFC  3344] 


[RFC  3344] 


Figure  12.  Registration  Reply  Message  (After:  [4]  &  [6]). 
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Field 

Description 

IP  Header 

Source 

Address 

Foreign  agent :  Copied  from  IP  destination  address  of  registration  request.  If  "All  Agents  Multicast" 
address  was  used,  interface  address  from  which  reply  is  sent  must  be  used. 

Home  agent :  Copied  from  IP  destination  address  of  registration  request.  If  a  multicast  or  broadcast 
address  was  used,  home  agent's  unicast  IP  address  is  used  for  this  field. 

Destination 

Address 

Foreign  agent:  If  it  generates  a  registration  reply  to  reject  the  request  and  the  home  address  field  in 
request  is  not  0.0. 0.0,  home  address  is  used  as  the  destination  address.  If  it  is  relaying  a  reply  from 
the  home  agent  and  the  home  address  field  is  not  0.0. 0.0,  home  address  is  used  as  the  destination 
address.  Otherwise,  the  destination  address  is  set  to  255.255.255.255. 

Home  agent :  Copied  from  IP  source  address  of  registration  request. 

UDP  Header 

Source  Port 

A  value  of  434  is  reserved  for  Mobile  IP  registration  messages. 

Destination 

Port 

Copied  from  UDP  source  port  of  the  registration  request. 

Fixed-Length  Portion  of  Registration  Reply 

Type 

A  type  field  of  3  identifies  message  as  a  registration  reply. 

Code 

A  value  indicating  the  result  of  the  registration  request. 

Lifetime 

If  code  field  indicates  that  the  registration  was  accepted,  the  lifetime  field  is  set  to  the  number  of 
seconds  remaining  before  the  registration  is  considered  to  be  expired.  A  value  of  0  indicates  that  the 
mobile  node  has  been  de-registered.  If  the  code  field  indicates  that  the  registration  was  denied,  the 
contents  of  the  lifetime  field  are  unspecified  and  must  be  ignored  upon  reception. 

Home  Address 

IP  address  of  the  mobile  node. 

Home  Agent 

IP  address  of  the  mobile  node's  home  agent. 

Identification 

A  64-bit  number  used  for  matching  registration  requests  with  registration  replies,  and  for  protecting 
against  replay  attacks  of  registration  messages.  Value  is  computed  based  on  the  identification  field 
from  the  mobile  node's  registration  request,  and  on  the  style  of  replay  protection  used  in  the  security 
context  between  the  mobile  node  and  its  home  agent.  Details  will  be  covered  under  the  Security 
Considerations  section  of  this  chapter. 

Extensions 

The  fixed-length  portion  of  the  registration  reply  is  followed  by  one  or  more  extensions  that  are 
described  in  the  subsequent  sections  of  this  chapter.  An  authorization-enabling  extension  must  be 
included  in  all  registration  replies  returned  by  the  home  agent. 

Table  3.  Registration  Reply  Message  Fields. 


4.  Mobile  Node’s  Role 

A  mobile  node  will  register  with  its  home  agent  by  sending  registration  requests 
whenever  it  detects  that  there  is  a  change  in  its  network  connectivity.  This  enables  the 
home  agent  to  create  or  update  mobility  bindings  for  the  mobile  node  when  it  is  away 
from  home,  as  well  as  delete  the  mobile  node’s  mobility  bindings  when  it  returns  home. 
A  mobile  node  will  re-register  with  its  foreign  agent  if  it  detects  that  the  foreign  agent  has 
rebooted,  or  when  its  current  registration  lifetime  is  about  to  expire. 

A  mobile  node  receives  registration  replies  from  the  home  agent  and/or  the 
foreign  agent  in  response  to  its  registration  requests.  Registration  replies  indicate  if  a 
registration  request  was  accepted,  or  if  it  was  denied  by  the  home  agent  or  foreign  agent. 
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A  mobile  node  performs  validity  checks  for  received  registration  replies  to  determine  if  it 
should  accept  or  discard  the  reply.  Figure  13  illustrates  the  process  of  handling  a 
registration  reply  that  is  received  by  a  mobile  node. 


Figure  13.  Processing  a  Registration  Reply  received  by  a  Mobile  Node. 
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5.  Foreign  Agent’s  Role 

A  foreign  agent  plays  mostly  a  passive,  “middleman”,  role  in  the  Mobile  IP 
registration  process.  A  foreign  agent  relays  registration  requests  and  replies  between  the 
mobile  node  and  its  home  agent.  It  will  only  generate  a  registration  reply  if  it  could  not 
support  the  services  requested  by  the  mobile  node.  In  the  case  where  the  foreign  agent’s 
care-of  address  is  used  in  the  registration  process,  the  foreign  agent  will  be  responsible 
for  decapsulating  IP  packets  sent  by  the  home  agent  for  delivery  to  the  mobile  node. 

Every  foreign  agent  maintains  a  visitor  list  to  capture  each  pending  or  current 
registration  request  it  processes  for  a  mobile  node.  The  foreign  agent  may  delete  any 
pending  registration  request  if  it  has  been  pending  for  more  than  seven  seconds. 
Optionally,  the  foreign  agent  may  also  share  mobility  security  associations  with  home 
agents  or  mobile  nodes,  in  which  case  the  appropriate  authentication  extensions  must  be 
included  and  processed  when  relaying  such  registration  requests  and  replies.  Figures  14 
and  15  describe  the  process  of  handling  registration  requests  and  replies  received  by  the 
foreign  agent. 
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1 .  Foreign  agent  receives  a 
registration  request. 


Invalid  UDP  checksum 


2.  Checks  UDP  checksum. 


Valid  UDP  checksum 


3.  Checks  if  reserved  fields  has  non-zero  bits. 


4.  Checks  if  invalid  care-of  address  is 
included  when  ‘D’  bit  is  set  to  0. 


Extension  absent, 
or  invalid 

authenticator  value 


Nq  5.  Checks  presence  of  authentication  extension  & 
,r  authenticator  value  if  mobility  security  association 
exists  between  foreign  agent  &  mobile  node. 


Extension  present  & 
valid  authenticator  , 


6.  Checks  if  requested  lifetime  is  too  long. 


Foreign  agent  rejects 
invalid  request  & 
sends  reply  to  mobile 
node  with 
appropriate  code. 


7.  Checks  if  home  agent’s  address  is  on  its 

network  interfaces. 

\  No 


8.  Checks  if  it  serves 
as  home  agent  for 
mobile  node. 


Silently  discards 
request. 


Foreign  agent  processes 
request  as  described  under 
Home  Agent’s  Role  in  this 
chapter. 


Foreign  agent  accepts  valid 
request,  processes  and  appends 
any  extensions  as  appropriate, 
adds  request  to  pending  visitor  list 
&  relays  request  to  mobile  node’s 
home  agent. 


Figure  14.  Processing  a  Registration  Request  received  by  a  Foreign  Agent. 
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1 .  Foreign  agent  receives  a 
registration  reply. 


Invalid  UDP  checksum 


2.  Checks  UDP  checksum. 


Valid  UDP  checksum 


Pending  request  not  found 


3.  Searches  pending  visitor  list  for 
registration  request  with  the  same  mobile 
node  home  address  specified  in  reply. 


Pending  request  found 


Identification  fields 
do  not  match 


4.  Compares  low-order  32  bits  of  identification 
field  in  reply  to  the  pending  request. 


Valid  identification 

Extension  absent,  or  invalid  ^ 
authenticator  value 


5.  Checks  presence  of  authentication  extension  & 
authenticator  value  if  mobility  security  association 
exists  between  foreign  agent  &  home  agent. 


Extension  present  & 
valid  authenticator  , 


6.  Checks  code  field  in  valid  reply  to  see  if 
home  agent  accepts  registration  request. 


Rejects  registration 
request  &  sends  reply  to 
mobile  node  with 
appropriate  code. 


Rejects 


Accepts 


7.  Checks  lifetime  field  of  reply. 


Lifetime  is  zero 


Lifetime  is 
non-zero 


Silently  discards  \ 
reply. 


Deletes  request 
entry  from  pending 
visitor  list. 


Updates  lifetime  field 
in  visitor  list  entry  for 
mobile  node. 


Deletes  visitor  list 
entry  for  mobile 
node. 


Processes  and  appends  any  extensions  as  appropriate 
&  relays  reply  to  mobile  node. 


Figure  15.  Processing  a  Registration  Reply  received  by  a  Foreign  Agent. 
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6.  Home  Agent’s  Role 

A  home  agent  plays  a  crucial  role  in  the  Mobile  IP  registration  process.  A  home 
agent  receives  registration  requests  from  the  mobile  node,  updates  its  record  of  mobility 
bindings  for  the  mobile  node,  and  generates  appropriate  registration  reply  in  response  to 
each  request.  Every  home  agent  maintains  a  list  of  mobility  bindings  for  each  mobile 
node  that  it  serves  as  home  agent. 

To  ensure  the  authenticity  of  a  registration  request  in  order  to  prevent  against 
malicious  DoS  or  traffic  redirection  types  of  attacks,  all  mobile  nodes  that  will  be  served 
by  a  home  agent  must  have  been  previously  identified  and  configured  with  the 
appropriate  mobility  security  associations  with  the  home  agent.  Optionally,  the  home 
agent  may  also  maintain  mobility  security  associations  with  foreign  agents,  in  which  case 
the  appropriate  authentication  extensions  must  be  included  and  processed  when 
responding  to  such  registration  requests  and  generating  the  corresponding  registration 
replies.  Figure  16  describes  the  process  of  handling  a  registration  request  that  is  received 
by  a  home  agent. 
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1 .  Home  agent  receives  a 
registration  request. 


Invalid  UDP  checksum 


2.  Checks  UDP  checksum. 


Valid  UDP  checksum 

Extension  absent,  or  invalid 
authenticator  value 


3.  Checks  presence  of  authentication  extension 
(for  mobility  security  association  between  mobile 
node  &  home  agent)  &  authenticator  value. 


Extension  present  & 
valid  authenticator  , 

Incorrect 


4.  Checks  if  registration  identification  is 
correct  using  security  context  indexed  by  SPI 
within  authorization  enabling  extension. 


Correct 

Extension  absent, 

or  invalid  ...? 

authenticator  value/^ 


5.  Checks  presence  of  authentication  extension  & 
authenticator  value  if  mobility  security  association 
exists  between  home  agent  &  foreign  agent. 


Extension  present  & 
valid  authenticator  ■ 


6.  Checks  if  registration  request  is  sent  to  subnet- 
directed  broadcast  address  of  home  network. 


Home  agent  rejects 
invalid  request  &  yes 

sends  reply  to  mobile  ◄ - 

node  with 
appropriate  code. 


7.  Checks  if  reserved  fields  has  non-zero  bits. 


Silently  discards 
request. 


8.  Is  home  agent  able  to  accommodate  request? 


9.  Home  agent  processes  valid  registration 
request. 
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Figure  16.  Processing  a  Registration  Request  received  by  a  Home  Agent. 


D.  ROUTING 

Once  the  mobile  node  discovers  its  current  location  through  agent  discovery  and 
communicates  this  information  to  its  home  agent  via  the  registration  process,  routing  is 
the  next  process  that  must  take  place  to  facilitate  the  delivery  of  IP  packets  to  and  from 
the  mobile  node. 

1.  Tunneling 

As  highlighted  at  the  beginning  of  this  chapter,  one  of  the  major  goals  of  Mobile 
IP  is  for  a  mobile  node  to  keep  its  IP  address  constant  when  it  roams  from  network  to 
network,  at  the  same  time  maintaining  ongoing  communications  with  correspondent 
nodes.  Supporting  this  with  traditional  routing  protocols  would  require  the  propagation  of 
host  routes  for  each  mobile  node,  which  is  clearly  not  robust  and  scaleable.  Instead,  the 
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approach  adopted  by  Mobile  IP  is  protocol  tunneling,  where  host  routes  are  inserted  in  at 
most  two  devices,  i.e.,  the  home  agent  and  foreign  agent,  and  single-hop  logical  links,  or 
tunnels,  are  established  from  the  home  agent  to  the  edge  of  the  foreign  network  where  the 
mobile  node  currently  resides.  The  tunnel  endpoint  in  the  foreign  network  can  either  be  a 
foreign  agent’s  care-of  address,  or  a  mobile  node’s  co-located  care-of  address.  The  home 
agent  then  forwards  IP  packets  to  the  mobile  node  using  this  tunnel.  Figure  17  depicts 
these  two  different  tunnel  options  that  can  be  established  by  a  home  agent. 


Co-located 


Mobile  IP  uses  IP-in-IP  encapsulation  [17]  as  the  default  tunneling  protocol  to 
deliver  IP  packets  via  the  tunnel  established  by  the  home  agent.  An  IP  packet  is 
encapsulated  as  payload  in  another  IP  packet,  with  the  tunnel  endpoints  reflected  in  the 
source  and  destination  address  fields  of  the  new  IP  header.  The  home  agent  encapsulates 
IP  packets  destined  for  the  mobile  node  and  sends  them  across  the  tunnel.  Upon  leaving 
the  tunnel,  the  encapsulated  IP  packet  is  decapsulated  either  by  the  foreign  agent  for 


31 


delivery  to  the  mobile  node;  or  by  the  mobile  node  for  delivery  to  its  higher  application 
layers.  Each  home  agent,  foreign  agent,  and  mobile  node  using  a  co-located  care-of 
address  must  be  able  to  support  IP-in-IP  encapsulation,  with  optional  support  for  minimal 
encapsulation  [14]  and  Generic  Routing  Encapsulation  (GRE)  [15]. 

2.  Triangle  Routing 

A  mobile  node  operates  without  the  support  of  mobility  services  when  it  is 
connected  to  its  home  network.  IP  packets  sent  to  and  from  the  mobile  node  are  routed 
via  the  standard  routing  mechanisms.  When  the  mobile  node  roams  to  a  foreign  network 
and  is  registered  away  from  home,  its  home  agent  intercepts  IP  packets  destined  to  the 
mobile  node1  and  tunnels  them  to  the  mobile  node’s  registered  care-of  address.  At  the 
care-of  address,  the  foreign  agent  decapsulates  and  delivers  the  IP  packets  to  the  mobile 
node;  or  the  mobile  node  performs  its  own  decapsulation.  IP  packets  sent  by  the  mobile 
node  on  the  foreign  network  are  routed  via  the  standard  routing  mechanisms  to  its 
correspondent  node.  Consequently,  an  asymmetric  routing  path,  commonly  referred  to  as 
triangle  routing  illustrated  in  Figure  18,  is  established  for  delivery  of  IP  packets  to  and 
from  a  mobile  node  when  it  is  away  from  its  home  network. 


1  IP  unicast  packets  destined  for  the  mobile  node.  A  home  agent  will  only  forward  IP  broadcast 
packets  to  a  mobile  node  if  the  mobile  node  has  set  the  ‘B’  bit  in  its  registration  request.  If  a  foreign  care-of 
address  is  used,  the  home  agent  needs  to  first  encapsulate  the  IP  broadcast  packet  into  an  IP  unicast  packet 
addressed  to  the  mobile  node  prior  to  tunneling  it  to  the  foreign  agent  (i.e.,  nested  encapsulation).  The 
foreign  agent  will  then  decapsulate  and  send  the  unicast  encapsulated  packet  to  the  mobile  node.  Such 
nested  encapsulation  is  not  required  if  a  mobile  node  uses  a  co-located  care-of  address. 
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Correspondent  Node 


3.  ARP  and  its  Variants 

Besides  tunneling,  Address  Resolution  Protocol  (ARP)  [18]  and  its  variants  are 
used  in  a  Mobile  IP  environment2  to  ensure  proper  delivery  of  IP  packets  to  and  from  a 
mobile  node.  ARP  is  used  when  a  node  wishes  to  resolve  (discover)  a  target  node’s 
Ethernet  link-layer  address  from  its  IP  address. 

A  proxy  ARP  [19]  is  an  ARP  reply  sent  by  a  node,  i.e.,  the  proxy,  on  behalf  of 
another  node  that  is  unable  to  respond  to  its  own  ARP  requests.  The  recipient  of  this 
reply  will  then  associate  the  proxy  node’s  link-layer  address  with  the  IP  address  of  the 
original  target  node. 

A  gratuitous  ARP  [8]  is  an  ARP  packet  sent  by  a  node  to  cause  other  nodes  to 
spontaneously  update  an  entry  in  their  ARP  cache,  to  immediately  reflect  the  change  in 
link-layer  address  associated  with  the  IP  address  advertised  in  the  ARP  packet.  A 
gratuitous  ARP  uses  either  an  ARP  request  or  ARP  reply  packet.  Both  the  ARP  sender 
and  target  protocol  addresses  are  set  to  the  IP  address  of  the  cache  entry  to  be  updated, 

2  This  section  is  applicable  to  all  home  networks  that  use  ARP  for  address  resolution. 
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and  the  ARP  sender  hardware  address  is  set  to  the  link-layer  address  to  be  reflected  in  the 
updated  cache  entry.  The  target  hardware  address  is  also  set  to  the  same  link-layer 
address  if  an  ARP  reply  packet  is  used. 

To  ensure  the  correct  operation  of  the  Mobile  IP  protocol,  it  is  important  for  the 
use  of  ARP,  proxy  ARP,  and  gratuitous  ARP  to  adhere  to  a  specific  sequence  when  a 
mobile  node  roams  away  from  home  or  when  it  returns  home.  Figures  19  and  20  illustrate 
the  use  of  ARP  and  its  variants  for  the  scenario  when  a  mobile  node  leaves  its  home 
network;  and  the  scenario  when  the  mobile  node  returns  to  its  home  network. 


Disable  ARP  processing 
1 


Q 


Registration  Request  using 


1 .  Mobile  node  disables  its  own  processing  of  any  ARP  requests  it  may  subsequently  receive  that 
request  link-layer  address  corresponding  to  its  home  address  (except  when  necessary  to  communicate 
with  foreign  agents  on  visited  networks). 

2.  Mobile  node  transmits  its  registration  request. 

3.  Home  agent  accepts  registration  request  &  sends  reply. 

4.  Home  agent  sends  gratuitous  ARP  to  all  nodes  on  the  home  network  by  setting  its  link-layer  address 
as  that  for  the  mobile  node’s  home  address. 

5.  Home  agent  uses  proxy  ARP  to  reply  to  ARP  requests  that  it  receives  on  the  home  network, 
requesting  for  the  mobile  node’s  link-layer  address. 

Figure  19.  ARP  Operation  when  a  Mobile  Node  leaves  its  Home  Network. 
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Enables  ARP  processing 

^  Gratuitous  ARP 


Disable  Proxy  ARP  for 
Mobile  Node 


Q 


Mobile  Node 


a 


1 .  Mobile  node  re-enables  its  own  processing  of  any  ARP  requests  it  may  subsequently  receive 
that  request  link-layer  address  corresponding  to  its  home  address. 

2.  Mobile  node  performs  a  gratuitous  ARP  for  itself. 

3.  Mobile  node  transmits  its  de-registration  request. 

4.  Home  agent  accepts  de-registration  request  &  sends  reply. 

5.  Home  agent  stops  using  proxy  ARP  to  reply  to  ARP  requests  that  it  receives  on  the  home 
network,  requesting  for  the  mobile  node’s  link-layer  address. 

6.  Home  agent  uses  mobile  node’s  link-layer  address  to  send  gratuitous  ARP  on  behalf  of  mobile 
node  to  all  nodes  on  the  home  network. 


Figure  20.  ARP  Operation  when  a  Mobile  Node  returns  to  its  Home  Network. 


E.  MOBILE  IP  HANDOFF 

In  order  for  a  mobile  node  to  roam  from  one  network  to  another  and  continue  its 
ongoing  communications  with  other  correspondent  nodes,  it  must  be  able  to  perform 
move  detection  through  agent  discovery  and  register  its  new  location  with  its  home  agent 
through  the  registration  process.  Routing  information  is  then  updated  to  facilitate  the 
delivery  of  IP  traffic  to  the  mobile  node.  Since  Mobile  IP  is  a  layer  3  protocol,  a  change 
in  routing  to  facilitate  the  continued  delivery  of  IP  traffic  to  the  mobile  node  is 
considered  a  Mobile  IP  handoff. 

There  are  three  scenarios  in  which  a  Mobile  IP  handoff  can  be  initiated,  namely, 
when  a  mobile  node  leaves  it  home  network,  when  a  mobile  node  roams  from  one  foreign 
network  to  another  foreign  network,  and  when  a  mobile  node  returns  to  its  home  network. 
In  addition  to  using  agent  discovery,  a  mobile  node  may  rely  on  link-layer  mechanisms  to 
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decide  that  it  has  moved  to  a  different  network.  One  such  mechanism  is  the  wireless  link- 
layer  handoff  that  will  be  described  in  the  next  chapter. 


F.  SECURITY  CONSIDERATIONS 

The  Mobile  IP  registration  procedure  is  potentially  vulnerable  to  Denial-of- 
Service  (DoS)  and  traffic  redirection  types  of  attacks,  as  a  malicious  user  could 
masquerade  as  a  mobile  node  and  send  bogus  registration  requests  to  the  mobile  node’s 
home  agent,  resulting  in  tunneling  of  the  mobile  node’s  IP  packets  to  the  malicious  user. 
To  prevent  against  such  attacks,  the  Mobile  IP  protocol  requires  that  all  registration 
messages  between  the  mobile  node  and  its  home  agent  be  authenticated.  Specifically, 
RFC  3344  [4]  states  that 

Registration  messages  between  a  mobile  node  and  its  home  agent  MUST 
be  authenticated  with  an  authorization-enabling  extension,  e.g.,  the 
Mobile-Home  Authentication  Extension. 


1.  Authentication  Extensions 

Authentication  extensions  are  used  by  the  Mobile  IP  protocol  to  provide  peer 
authentication  and  message  integrity.  An  authentication  extension  is  appended  to  the  end 
of  a  registration  request  or  reply  message  that  contains  relevant  security  information  to 
authenticate  and  protect  the  integrity  of  the  registration  process.  An  authentication 
extension  that  facilitates  the  acceptance  of  a  registration  request  or  reply  message  by  a 
recipient  of  the  message  is  also  referred  to  as  an  authorization-enabling  extension.  Figure 
21  depicts  the  authentication  extension  that  follows  after  a  registration  request  or  reply 
message,  and  Table  4  describes  its  corresponding  fields. 
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0  1  2  3  4  5  6  7 

8  9  0  1  2  3  4  5 

6789012345678901 

Registration  Request  /  Reply 

Type 

Length 

SPI... 

...  SPI  (cont.) 

Authenticator... 

I  Extensions...  I 

I _ J 


Registration 
Request  /  Reply 
[RFC  3344] 


Authentication 

Extension 


[RFC  3344] 


[RFC  3344] 


Figure  21.  Authentication  Extension  (After:  [4]). 
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Field 

Description  1 

Authentication  Extension 

Type 

Mobile-Home  Authentication  Extension  has  a  value  of  32. 

Mobile-Foreign  Authentication  Extension  has  a  value  of  33. 

Foreign-Home  Authentication  Extension  has  a  value  of  34. 

Length 

4  bytes  (for  SPI)  plus  number  of  bytes  in  the  Authenticator. 

SPI 

4  bytes  Security  Parameter  Index. 

Authenticator 

Variable  length. 

Table  4.  Authentication  Extension  Fields. 


The  Mobile  IP  protocol  uses  three  authentication  extensions  to  protect  its 
registration  request  and  reply  messages,  namely,  the  mobile-home  authentication 
extension,  mobile-foreign  authentication  extension  and  foreign-home  authentication 
extension. 

a.  Mobile-Home  Authentication  Extension  (MHAE) 

The  mobile-home  authentication  extension  must  be  present  in  all 
registration  requests  initiated  by  the  mobile  node,  as  well  as  all  registration  replies 
generated  by  the  home  agent. 

b.  Mobile-Foreign  Authentication  Extension  (MFAE) 

The  mobile-foreign  authentication  extension  must  be  included  in 
registration  requests  and  replies  whenever  a  mobility  security  association  exists  between 
the  mobile  node  and  foreign  agent. 

c.  Foreign-Home  Authentication  Extension  (FHAE) 

The  foreign-home  authentication  extension  must  be  included  in 
registration  requests  and  replies  whenever  a  mobility  security  association  exists  between 
the  foreign  agent  and  home  agent. 

2.  Security  Association 

Mobile  IP  entities  must  first  share  a  security  relationship  in  order  to  use  an 
authentication  extension.  The  security  relationship  is  predefined  using  a  set  of  parameters 
configured  into  each  node,  which  are  collectively  known  as  a  security  context.  A  security 
context  identifies  the  encryption  algorithm  and  mode,  the  shared  key  used  by  a  pair  of 
nodes,  and  the  method  of  replay  protection  used.  A  specific  security  context  in  an 
authentication  extension  is  identified  by  a  four  byte  Security  Parameter  Index  (SPI).  A 
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group  of  one  or  more  security  contexts  that  are  shared  with  a  peer  node  is  referred  to  as  a 
security  association. 

a.  Encryption  Algorithm  and  Mode 

The  authenticator  value  computed  for  each  authentication  extension  is  a 
Message  Authentication  Code  (MAC),  which  is  a  unique  fingerprint  for  each  registration 
message.  HMAC-MD5  [20]  is  the  default  algorithm  used  to  compute  a  128-bit  message 
digest  of  the  registration  message.  The  computed  authenticator  value  will  protect  the 
registration  request  or  reply  data,  all  prior  extensions  in  their  entirety,  as  well  as  the  type, 
length  and  SPI  of  the  authentication  extension.  The  SPI  within  any  of  the  authentication 
extensions  defines  the  security  context  that  is  used  to  compute  the  authenticator  value  and 
must  be  used  by  the  recipient  to  verify  the  received  value. 

b.  Shared  Key 

The  authenticator  value  is  computed  using  a  key  that  is  shared  between  a 
pair  of  nodes.  The  sender  of  the  message  uses  the  shared  key  to  compute  the  authenticator 
value  (i.e.,  the  MAC)  and  places  it  in  the  authentication  extension.  The  recipient  uses  the 
same  shared  key  to  compute  the  authenticator  over  the  received  registration  message, 
compares  the  result  to  the  authenticator  value  in  the  authentication  extension,  and  accepts 
the  authentication  only  if  the  two  values  match.  The  default  key  used  for  HMAC-MD5  in 
the  Mobile  IP  registration  process  is  128  bits  long  and  is  represented  as  a  32-character 
hexadecimal  string.  In  order  for  keyed  MD5  authentication  to  be  useful,  the  128-bit  key 
must  be  both  secret,  i.e.,  known  only  to  communicating  peers,  and  pseudo-random. 

c.  Replay  Protection 

To  prevent  the  replay  of  captured  registration  requests  by  a  malicious  user, 
the  Mobile  IP  registration  process  offers  two  methods  of  replay  protection.  All  mobile 
nodes  and  home  agents  must  implement  timestamp-based  replay  protection,  with  optional 
support  for  replay  protection  based  on  nonce.  Figures  22  and  23  illustrate  the  use  of  the 
replay  protection  mechanisms  based  on  timestamp  and  nonce. 
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Q 


1.  Insert  current  timestamp,  T1, 
into  registration  request. 


Mobile  Node 


THA  =  Home  Agent’s  Timestamp 


2.  Sends  Registration  Request  with  T1. 


• - 

4a.  Rejects  Registration  Request  with 
appropriate  error  code. 

- ► 

3a.  Is  T1  greater  than 
previous  timestamps  for 
'  j  mobile  node? 

*  3b.  Is  |T1  -  THA|  <  7  secs? 

No 

W 

4b.  Accepts  Registration  Request. 

◄ - 

- • 

Yes 

1 .  Mobile  node  inserts  current  timestamp  into  registration  request  by  setting  the  identification  field  to 
a  64-bit  value  formatted  as  specified  by  the  Network  Time  Protocol  (NTP)  [21].  Identification  value 
must  be  greater  than  that  used  by  previous  registration  requests,  as  the  home  agent  uses  this  as  a 
sequence  number. 

2.  Mobile  node  sends  the  registration  request  to  its  home  agent. 

3.  Home  agent  checks  timestamp  value  in  identification  field: 

a.  Is  it  greater  than  all  previously  accepted  timestamps  for  mobile  node? 

b.  Does  it  fall  within  the  allowable  range  from  the  home  agent’s  current  timestamp? 

4a.  If  either  of  the  checks  in  3  fails,  the  home  agent  rejects  the  registration  request  by  sending  a 
reply  with  an  appropriate  error  code. 

4b.  Home  agent  accepts  the  registration  request  only  if  the  timestamp  value  passes  the  checks  in  3. 
Figure  22.  Replay  Protection  using  Timestamp  (After:  Ref.  [5]). 
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1.  Generates  nonce  for  low-order 
32  bits  of  Identification. 

Q 

Mobile  Node 


2.  Sends  Registration  Request  with  Mobile 
Node’s  nonce  in  low-order  32  bits  of 
Identification  field. 


4.  Sends  Registration  Reply  with  Home  Agent’s 
nonce  in  high-order  32  bits,  Mobile  Node’s 
nonce  in  low-order  32  bits  of  Identification  field. 

—  w  Qf  identification. 

Copies  low-order  32 
bits  from  request. 

5.  Checks  low-order 
32  bits  in  reply  and 
saves  high-order  32 
bits  for  future  request. 


Q 

3.  Generates  nonce 
for  high-order  32  bits 


Sending  future  Registration  Request... 

Q 

1.  Generates  new  nonce 
for  low-order  32  bits  of 
Identification.  Uses 
previously  saved  high- 
order  32  bits  from  home 
agent’s  reply. 

• - ► 

Figure  23.  Replay  Protection  using  Nonce. 


2.  Sends  Registration  Request  with  Home  Agent’s 
nonce  in  high-order  32  bits,  newly  generated 
nonce  in  low-order  32  bits  of  Identification  field. 


3.  IP  Spoofing 

IP  spoofing  enables  a  malicious  user  to  gain  unauthorized  access  to  networked 
resources  by  assuming  the  IP  address  of  an  authorized  network  node  [22],  This  is 
possible  since  the  IP  standard  defines  routing  of  IP  packets  to  be  based  only  upon 
destination  address  [1].  To  protect  against  IP  spoofing,  many  routers  that  are  connected  to 
the  Internet  implement  ingress  filtering,  where  IP  packets  whose  source  address  appears 
to  be  topologically  incorrect  are  dropped. 

Mobile  IP  relies  on  the  standard  routing  based  on  destination  address  in  order  for 
a  mobile  node  to  retain  its  IP  address  when  it  roams  away  from  its  home  network.  As  a 
mobile  node’s  home  address  will  be  considered  topologically  incorrect  when  it  is 
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connected  to  a  foreign  network,  IP  packets  originated  from  the  mobile  node  in  the  foreign 
network  may  potentially  be  dropped.  To  support  the  proper  operation  of  Mobile  IP  in 
such  an  environment,  a  mobile  node  may  request  the  use  of  reverse  tunneling  [16]  during 
registration  with  its  home  agent.  In  this  case,  IP  packets  sent  by  the  mobile  node  will  be 
reverse-tunneled  back  to  the  home  agent  for  delivery  to  the  destination. 

4.  Open  Areas  of  Concern 

a.  Key  Management 

The  Mobile  IP  protocol  uses  keyed  MD5  as  its  authentication  mechanism. 
This  requires  the  management  of  shared  secret  keys  between  peer  nodes  that  have  a 
security  association.  As  key  distribution  is  difficult  in  the  absence  of  a  network  key 
management  protocol,  registration  messages  exchanged  with  the  foreign  agent  do  not 
need  to  be  authenticated.  This  will  potentially  subject  the  registration  process  to  traffic 
redirection  attacks  in  which  a  malicious  node  can  masquerade  as  a  foreign  agent  and  send 
bogus  agent  advertisements. 

b.  ARP  Usage 

As  described  under  the  Routing  section  of  this  chapter,  gratuitous  ARP  is 
used  to  force  recipients  of  the  ARP  packet  to  spontaneously  update  their  ARP  cache  for 
the  broadcast  entry.  Since  the  use  of  ARP  is  not  subjected  to  any  form  of  authentication, 
attackers  can  potentially  exploit  this  vulnerability  to  poison  the  ARP  cache  [23]  and 
result  in  malicious  traffic  redirection. 
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III.  IEEE  802.11  PROTOCOL  PRIMER 


A.  INTRODUCTION 

Wireless  networking  is  often  associated  with  mobility.  Wireless  data  networks 
free  users  from  the  tethers  of  an  Ethernet  cable  at  a  desk,  allowing  users  to  roam  freely 
and  stay  connected  to  the  network.  Several  wireless  technologies  are  available  for  the 
purpose  of  data  transmission;  however,  the  wireless  technology  based  on  the  IEEE 

802.11  standard  [24]  is  the  most  popular  and  widely  adopted  wireless  method  for 
networking  computers.  It  is  thus  appropriate  to  give  an  overview  of  how  the  IEEE  802.1 1 
protocol  operates,  so  as  to  appreciate  its  integration  with  the  Mobile  IP  protocol  to 
provide  seamless  mobility  when  a  user  wirelessly  roams  from  one  network  to  another. 

This  chapter  will  briefly  describe  the  IEEE  802.11  nomenclature  and  design, 
highlighting  the  two  types  of  network  modes  available  for  an  IEEE  802. 1 1  environment. 
The  chapter  will  then  introduce  the  fundamental  building  blocks  underlying  an  IEEE 

802.11  infrastructure  mode  network,  followed  by  the  basics  of  operation  of  this  mode. 
The  chapter  will  conclude  with  an  analysis  of  what  constitutes  a  “link  layer  handoff ’,  and 
how  this  handoff  integrates  with  the  mobility  mechanisms  of  the  Mobile  IP  protocol. 

It  is  not  the  intent  of  this  chapter  to  describe  the  operations  of  the  IEEE  802.11 
standard  at  length.  Sufficient  details  will  be  covered  to  set  the  stage  for  the  focus  of  this 
research.  Readers  can  refer  to  [25]  and  [26]  for  a  more  thorough  treatment  on  the  IEEE 

802. 1 1  operations  and  security  ramifications.  These  same  two  references  have  also  served 
as  the  main  source  of  information  for  the  concepts  illustrated  in  this  chapter. 


B.  IEEE  802.11  NOMENCLATURE  AND  DESIGN 

Before  delving  into  the  operations  of  the  IEEE  802.11  protocol,  it  is  appropriate 
to  describe  the  nomenclature  and  design  of  IEEE  802.11  wireless  networks,  in  order  to 
facilitate  understanding  of  the  concepts  underlying  the  IEEE  802.1 1  operation. 
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1.  Physical  Components 

IEEE  802.1 1  networks  are  comprised  of  four  major  physical  components,  namely, 
distribution  system,  access  points,  wireless  medium  and  stations.  Figure  24  depicts  the 
relationship  among  these  four  components. 


Wireless  Medium 


)) 


Figure  24.  Components  of  an  IEEE  802.1 1  Network  (After:  Ref.  [25]). 


a.  Distribution  System 

A  distribution  system  is  typically  a  backbone  network  that  is  used  to 
connect  multiple  access  points  servicing  a  large  coverage  area.  The  distribution  system  is 
used  to  transmit  frames3  from  one  access  point  to  another  access  point,  or  any  other 
network  destination — wired  or  wireless. 

b.  Access  Point 

An  access  point  performs  the  wireless-to-wired  bridging  function,  so  as  to 
convert  frames  received  on  an  IEEE  802. 1 1  wireless  network  into  other  type  of  frames  as 
appropriate  for  delivery  in  the  wired  environment. 

c.  Wireless  Medium 

The  IEEE  802.11  standard  uses  a  wireless  medium  to  transmit  frames 
from  one  location  to  another.  Several  physical  layers  have  been  defined  in  the  standard; 


3  A  frame  refers  to  a  Protocol  Data  Unit  (PDU)  at  layer  2,  i.e.,  the  Data  Link  layer,  of  the  Open 
Systems  Interconnection  (OSI)  reference  model. 
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however,  the  more  popular  wireless  medium  in  use  today  is  a  portion  of  the  radio 
frequency  (RF)  range  of  the  electromagnetic  spectrum. 


d.  Stations 

Stations  are  simply  computing  devices  with  wireless  network  interfaces. 


Depending  on  the  usage  scenario,  stations  can  range  from  portable  handheld  devices  to 
desktop  computers  with  wireless  network  interfaces. 

2.  Types  of  Networks 

IEEE  802.11  supports  two  types  of  network  modes,  specifically,  independent 
mode  and  infrastructure  mode. 


a.  Independent  Mode 

Stations  in  an  independent  network  mode  communicate  directly  with  each 


other,  and  thus,  must  be  in  direct  communication  range  with  all  the  participating  stations. 
Typically,  independent  network  mode  is  used  to  setup  a  wireless  network  for  a  small 
number  of  stations  to  serve  a  specific  purpose  within  a  short  time-frame.  Because  of  the 
small  size,  short  duration,  and  explicit  purpose,  independent  network  mode  is  sometimes 
referred  to  as  ad-hoc  network  mode.  Figure  25  illustrates  a  wireless  network  setup  based 
on  the  independent  mode. 


Wireless  Network 
Interface 


Station 


Figure  25.  Wireless  Network  in  Independent  Mode  (After:  Ref.  [25]). 
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b.  Infrastructure  Mode 

The  main  distinction  between  an  infrastructure  network  mode  and  an 
independent  network  mode  is  the  presence  of  an  access  point.  Access  points  are  used  for 
all  wireless  communications  between  stations  in  an  infrastructure  network  mode. 
Transmission  of  a  frame  from  one  station  to  another  station  requires  two  hops:  first,  the 
source  station  transmits  the  frame  to  the  access  point;  next,  the  access  point  transmits  the 
frame  to  the  destination  station.  Stations  in  an  infrastructure  network  mode  will  only  need 
to  stay  within  communication  range  with  the  access  point.  Figure  26  illustrates  a  wireless 
network  setup  based  on  the  infrastructure  mode. 


Figure  26.  Wireless  Network  in  Infrastructure  Mode  (After:  Ref.  [25]). 


3.  Building  Blocks  for  Wireless  Network  in  Infrastructure  Mode 

As  stated  in  the  earlier  section,  wireless  networks  configured  using  the 
independent  mode  are  typically  short-lived  and  service  only  a  small  group  of  users. 
Infrastructure  mode  is;  however,  the  appropriate  mode  for  creating  a  more  permanent  and 
scalable  wireless  networking  infrastructure  to  service  a  larger  group  of  users.  Moreover, 
wireless  networks  configured  based  on  the  infrastructure  mode  will  interoperate 
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seamlessly  with  the  Mobile  IP  environment,  and  were  thus  adopted  for  the  lab  setup 
described  in  the  next  chapter. 

a.  Basic  Service  Set  (BSS) 

The  fundamental  building  block  for  an  IEEE  802. 1 1  wireless  network  in 
infrastructure  mode  is  the  Basic  Service  Set  (BSS).  Stations  within  a  BSS  are  serviced  by 
an  access  point,  and  they  compete  for  the  same,  shared  wireless  medium.  Each  BSS  is 
assigned  a  BSS  Identifier  (BSSID),  which  corresponds  to  the  Media  Access  Control 
(MAC)  address  of  the  wireless  interface  in  the  access  point  servicing  the  BSS.  Figure  27 
shows  the  notion  of  a  BSS. 


((f) 


Access  Point 


Basic  Service  Set  (BSS) 


Figure  27.  Basic  Service  Set  (BSS)  (After:  Ref.  [25]). 
b.  Extended  Service  Set  (ESS) 

BSS  can  only  provide  service  coverage  up  to  a  certain  area  size,  beyond 
which,  the  IEEE  802. 1 1  standard  allows  for  wireless  networks  of  arbitrarily  large  size  to 
be  created  by  interconnecting  different  BSSs  to  form  an  Extended  Service  Set  (ESS).  An 
ESS  typically  utilizes  the  distribution  system  to  connect  the  various  BSSs,  as  depicted  in 
Figure  28. 


47 


Figure  28.  Extended  Service  Set  (ESS)  (After:  Ref.  [27]). 
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C.  IEEE  802.1 1  NETWORK  OPERATIONS 

IEEE  802.1 1  standard  is  a  member  of  the  IEEE  802  family  [28],  which  specifies  a 
series  of  standards  for  Local  Area  Network  (LAN)  and  Metropolitan  Area  Network 
(MAN)  technologies.  IEEE  802  standards  address  the  two  lowest  layers  of  the  Open 
Systems  Interconnection  (OSI)  reference  model,  the  physical  and  data  link4  layers.  IEEE 
802.2  standard  [29]  specifies  a  common  link  layer,  i.e.,  the  Logical  Link  Control  (LLC) 
layer,  which  can  be  used  by  any  lower  layer  LAN  technology.  IEEE  802. 1 1  standard  can 
be  considered  as  another  LAN  technology  that  utilizes  the  IEEE  802.2  /  LLC 
encapsulation.  The  IEEE  802.1 1  standard  includes  specification  for  both  the  physical  and 
Media  Access  Control  (MAC)  layers.  The  relationships  among  the  various  components  of 
the  IEEE  802  family  are  illustrated  in  Figure  29. 
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Figure  29. 


IEEE  802  Network  Technology  Family  Tree  (After:  Ref.  [25]  &  [28]). 


1.  Network  Services 

The  IEEE  802.11  standard  offers  nine  network  services:  three  of  the  services  are 
used  for  data  transmission;  the  remaining  six  services  are  used  for  management 
operations  to  track  the  current  location  of  stations  for  correct  frame  delivery.  Table  5 
summarizes  the  network  services  that  are  described  in  the  IEEE  802.1 1  standard. 


4  The  Data  Link  layer  of  the  OSI  reference  model  is  further  divided  into  two  sub-layers:  the  Logical 
Link  Control  (LLC)  sub-layer;  and  the  Media  Access  Control  (MAC)  sub-layer. 
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Service 

Type 

Description 

Distribution 

Data 

transmission 

An  access  point  uses  the  distribution  service  to  deliver  a  frame 
to  its  destination. 

Integration 

Data 

transmission 

The  distribution  system  uses  the  integration  service  to  deliver  a 
frame  to  an  IEEE  802  LAN  outside  the  wireless  network. 

Association 

Management 

operation 

Stations  are  required  to  register,  or  associate,  with  an  access 
point  in  order  to  send  or  receive  frames  in  the  BSS  served  by 
the  access  point.  The  registration  information  is  also  used  by  the 
distribution  system  to  determine  which  access  point  to  use  for 
frame  delivery  to  a  station. 

Reassociation 

Management 

operation 

When  a  station  moves  between  BSSs  within  an  ESS,  it  will 
evaluate  the  signal  strength  and  may  change  the  access  point 
with  which  it  is  currently  associated.  A  station  initiates  a 
reassociation  with  a  new  access  point  whenever  the  signal 
conditions  indicate  that  this  new  association  is  beneficial.  After 
reassociation  is  complete,  the  distribution  system  updates  its 
location  records  to  reflect  the  access  point  to  use  for  frame 
delivery  to  the  station. 

Disassociation 

Management 

operation 

Stations  may  use  the  disassociation  service  to  terminate  an 
existing  association.  Any  location  records  stored  within  the 
distribution  system  will  be  removed  when  stations  invoke  this 
service.  Stations  will  no  longer  be  attached  to  the  BSS  once 
disassociation  is  complete. 

Authentication 

Management 

operation 

An  access  point  uses  authentication  to  determine  the  identity  of 
the  station  prior  to  establishing  association  with  the  station. 

Deauthentication 

Management 

operation 

Deauthentication  terminates  an  authenticated  relationship,  along 
with  its  existing  association. 

Privacy 

Management 

operation 

The  privacy  service  provides  protection  against  potential 
eavesdropping  over  the  wireless  network. 

MSDU  Delivery 

Data 

transmission 

Stations  use  the  MAC  Service  Data  Unit  (MSDU)  delivery 
service  to  deliver  data  to  the  recipient. 

Table  5.  IEEE  802.1 1  Network  Services  (After:  Ref.  [25]). 

2.  IEEE  802.11  Framing 

IEEE  802.11  framing  is  much  more  elaborate  than  the  traditional  Ethernet 
framing  in  a  wired  environment,  as  the  use  of  the  wireless  medium  requires  additional 
management  features  and  corresponding  frame  types  to  provide  reliable  data  delivery 
service.  Three  frame  types  are  employed  to  support  the  operations  of  the  IEEE  802.11 
protocol,  namely,  data  frames,  control  frames,  and  management  frames. 
a.  Data  Frames 

Data  frames  are  used  to  transmit  data  from  station  to  station.  Data  frames 
carry  higher-level  protocol  data  in  the  frame  body.  Different  types  of  data  frames  exist, 
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depending  on  whether  the  frames  are  used  for  contention-based  service  or  contention-free 
service5.  As  contention-free  service  is  not  widely  implemented,  this  section  will  focus 
only  on  frames  used  for  contention-based  service.  Table  6  lists  the  data  frames  used  for 
contention-based  service. 


Frame  Type 

Carries  Data? 

Description 

Data 

Yes 

Frames  of  the  data  sub-type  are  used  solely  for  the  purpose  of  moving 
the  frame  body  from  one  station  to  another. 

Null 

No 

Null  frames  are  used  by  the  stations  to  inform  the  access  point  of 
changes  in  power-saving  status.  The  access  point  will  then  need  to 
buffer  frames  for  the  station  when  the  station  sleeps. 

Table  6.  IEEE  802.1 1  Data  Frames. 


b.  Control  Frames 

Control  frames  are  used  to  administer  access  to  the  wireless  medium. 
Control  frames  work  in  conjunction  with  data  frames  to  provide  reliable  data  delivery 
from  station  to  station.  Table  7  lists  the  control  frames  provided  by  the  IEEE  802.11 
protocol. 


Frame  Type 

Function 

Description 

Request  to  Send 
(RTS) 

Carrier  sensing 
using  CSMA/CA 

An  RTS  frame  is  sent  by  a  station  whenever  it  has  a  unicast  frame  to 
transmit.  The  RTS  frame  serves  to  reserve  the  wireless  medium  for 
transmission,  at  the  same  time  preventing  any  stations  hearing  the 

RTS  frame  from  sending  more  frames. 

Clear  to  Send 
(CTS) 

Carrier  sensing 
using  CSMA/CA 

A  CTS  frame  is  sent  by  the  access  point  in  response  to  an  RTS. 

Similar  to  the  RTS  frame,  the  CTS  frame  serves  to  prevent  any 
stations  in  the  vicinty  from  sending  more  frames. 

Acknowledgment 

(ACK) 

Positive 

acknowlegment 

ACK  frames  are  used  for  the  positive  acknowledgment  of  any  unicast 
frames  sent  in  the  wireless  medium. 

Power-Save  Poll 
(PS-Poll) 

Power  savings 
option 

When  a  station  wakes  from  a  power-saving  mode,  it  sends  a  PS-Poll 
frame  to  the  access  point  to  retrieve  any  frames  buffered  for  it  when  it 
was  in  power-saving  mode. 

Table  7.  IEEE  802.1 1  Control  Frames. 
c.  Management  Frames 

Management  frames  are  used  to  perform  supervisory  functions,  so  as  to 
facilitate  a  station’s  ability  to  gain  access  to  a  wireless  network  in  order  to  send  and 


5  IEEE  802.11  supports  contention-based  service  and  contention-free  service.  Contention-based 
service  functions  analogously  to  the  traditional  Ethernet’s  Carrier  Sense  Multiple  Access  with  Collision 
Detection  (CSMA/CD)  [30],  where  stations  need  to  compete  for  the  shared  medium  in  order  to  transmit 
data.  (IEEE  802.1 1  uses  Carrier  Sense  Multiple  Access  with  Collision  Avoidance,  i.e.,  CSMA/CA,  for  this 
purpose.)  Contention-free  service,  on  the  other  hand,  ensures  that  the  medium  is  granted  to  a  station  for 
data  transmission  without  any  contention. 
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receive  data.  A  station  needs  to  go  through  a  three-step  procedure  when  it  first  initiates 
data  transmission  in  a  wireless  network:  first,  the  station  needs  to  search  for  a  compatible 
wireless  network  to  use  for  access,  i.e.,  scanning;  next,  the  wireless  network  must 
authenticate  the  station  intending  to  connect  to  the  network,  i.e.,  authentication;  and 
finally,  a  station  needs  to  be  associated  with  an  access  point  in  order  to  start  sending  and 
receiving  data  on  the  wireless  network,  i.e.,  association.  Table  8  describes  the  different 
management  frames  provided  by  the  IEEE  802.1 1  protocol. 


Frame  Type 

Function 

Description 

Beacon 

Scanning 

An  access  point  uses  beacon  frames  to  announce  the  existence  of  the 
wireless  network  for  which  it  serves.  Beacon  frames  are  transmitted  at 
regular  intervals  to  enable  stations  to  find  and  identify  a  network,  as 
well  as  to  allow  stations  to  configure  the  necessary  parameters  for 
joining  the  network. 

Probe  Request 

Scanning 

A  station  uses  a  probe  request  frame  to  scan  an  area  for  any  existing 
wireless  networks. 

Probe  Response 

Scanning 

An  access  point  sends  a  probe  response  frame  to  respond  to  a  probe 
request.  The  same  access  point  that  sends  beacon  frames  is 
responsible  for  responding  to  probe  requests. 

Authentication 

Authentication 

A  station  exchanges  authentication  frames  with  an  access  point  in 
order  to  authenticate  itself  to  the  access  point. 

Deauthentication 

Authentication 

A  station  uses  deauthentication  frames  to  terminate  an  existing 
authentication  relationship  with  an  access  point. 

Association 

Request 

Association 

After  a  station  has  identified  a  compatible  network  and  authenticated 
itself  to  the  network,  it  will  attempt  to  join  the  network  by  sending  an 
association  request  frame. 

Association 

Response 

Association 

An  access  point  checks  the  parameters  in  the  received  association 
request  and  verifies  that  they  match  the  parameters  of  the  network  the 
access  point  is  serving,  before  it  responds  with  an  association 
response. 

Reassociation 

Request 

Association 

A  station  sends  a  reassociation  request  frame  when  it  moves  from  one 
BSS  to  another  BSS;  or  when  it  leaves  the  coverage  area  of  an  access 
point  temporarily  and  rejoins  later. 

Reassociation 

Response 

Association 

An  access  point  uses  the  reassociation  response  frame  in  reply  to  a 
reassociation  request. 

Disassociation 

Association 

A  station  uses  a  disassociation  frame  to  terminate  an  existing 
association  relationship  with  the  access  point. 

Table  8.  IEEE  802.1 1  Management  Frames. 

3.  Operation  of  the  IEEE  802.11  Protocol  in  Infrastructure  Mode 

The  previous  sections  describe  the  network  services  and  framing  provided  by  the 
IEEE  802.11  protocol.  It  is  now  appropriate  to  summarize  the  rudiments  of  the  IEEE 
802.1 1  operation  in  infrastructure  mode,  illustrated  in  Figure  30. 


52 


Distribution  System 
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◄ — 
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5.  Sends  Authentication  frame 

6.  Replies  with  ACK 
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9.  Sends  Association  /  Reassociation  Request 


10.  Replies  with  ACK 


11.  Sends  Association  /  Reassociation  Response 


12.  Replies  with  ACK 


Association/  Reassociation/ 
Disassociation 


13.  Sends  RTS 


14.  Replies  with  CTS 


15.  Sends  Data 


16.  Replies  with  ACK 


17.  Sends  Data 


18.  Replies  with  ACK 


MSDU  Delivery  & 
Distribution 


Figure  30.  Operation  of  the  IEEE  802.1 1  Protocol  in  Infrastructure  Mode. 
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D.  MOBILITY  SUPPORT 


As  mentioned  in  the  beginning  of  this  chapter,  wireless  networking  is  often 
associated  with  mobility.  Stations  can  move  and  remain  connected  to  the  wireless 
network,  and  they  can  transmit  data  while  moving.  Mobility  can  result  in  one  of  the  three 
transition  scenarios,  namely,  no  transition,  BSS  transition,  and  ESS  transition. 

1.  No  Transition 

When  stations  move  within  the  same  service  coverage  area  offered  by  an  access 
point,  i.e.,  stations  move  within  the  same  BSS,  there  is  no  need  for  any  transition  to  take 
place,  as  stations  will  still  be  associated  with  the  same  access  point. 

2.  BSS  Transition 

BSS  transition  occurs  when  a  station  moves  from  one  BSS  to  another  BSS  within 
the  same  ESS.  IEEE  802.1 1  provides  link  layer  mobility,  in  which  the  station  reassociates 
with  the  access  point  of  the  BSS  it  has  moved  to,  before  it  continues  to  send  and  receive 
data.  Figure  3 1  depicts  a  BSS  transition. 


Figure  31.  BSS  Transition  (After:  Ref.  [25]). 
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3.  ESS  Transition 

ESS  transition  occurs  when  a  station  moves  from  one  ESS  to  another;  i.e.,  the 
station  moves  from  one  network  to  another.  As  IEEE  802.11  offers  only  link  layer 
mobility,  higher  layer  connections  will  be  disrupted  as  a  result  of  this  move.  Specifically, 
the  move  to  a  new  network  typically  requires  a  station  to  obtain  a  new  IP  address  as 
appropriate  on  the  new,  destination  network.  This  is  the  scenario  in  which  Mobile  IP  is 
required  to  offer  network  mobility,  working  hand-in-hand  with  the  IEEE  802.11  link 
layer  mobility  to  provide  a  seamless  transition  from  one  ESS  to  another  ESS.  Figure  32 
shows  such  an  ESS  transition. 
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Figure  32.  ESS  Transition  (After:  Ref.  [25]). 
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E.  IEEE  802.1 1  LINK  LAYER  HANDOFF 

The  three  different  transition  scenarios  discussed  in  the  previous  section  support 
the  mobility  of  a  station  in  a  wireless  environment.  To  continue  data  transmission  in  a 
new  BSS — whether  or  not  the  station  has  also  crossed  an  ESS  boundary — the  station  will 
need  to  go  through  the  process  of  scanning,  authentication,  and  reassociation  in  the  new 
destination  BSS.  This  three-step  process  corresponds  to  a  link  layer  handoff,  in  which  the 
association  of  the  station  is  transferred  between  access  points.  Figure  33  summarizes  the 
exchanges  corresponding  to  a  link  layer  handoff. 
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Figure  33.  IEEE  802.1 1  Fink  Layer  Handoff. 
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IV.  SETTING  UP  THE  MOBILE  IP  TEST  ENVIRONMENT 


A.  INTRODUCTION 

With  an  appreciation  of  the  operations  of  the  Mobile  IP  protocol  and  IEEE  802.1 1 
nomenclature  and  network  operations,  this  chapter  will  describe  the  considerations  for 
devising  a  test  setup  to  demonstrate  the  operations  of  Mobile  IP  version  4,  to  support  the 
roaming  of  an  IEEE  802.1 1  wirelessly  connected  host.  The  chapter  will  give  an  overview 
of  the  topological  design,  elaborating  on  the  hardware  and  software  requirements,  along 
with  any  constraints  and  restrictions.  After  which,  the  chapter  will  briefly  outline  the  test 
plan  for  collecting  the  performance  statistics.  Finally,  the  chapter  will  conclude  by 
explaining  the  methodology  for  data  collection  and  collation. 


B.  REFERENCE  ARCHITECTURE 

Setting  up  a  Mobile  IP  environment  that  supports  the  roaming  of  an  IEEE  802.1 1 
wirelessly  connected  host  entails  two  parts,  namely,  the  Mobile  IP  network,  and  the  IEEE 
802. 1 1  wireless  network. 

1.  Considerations 

It  is  the  intent  of  this  research  to  setup  a  controlled  environment  in  order  to  collect 
performance  statistics  for  the  constituent  components  underlying  the  handoff  mechanisms 
involved  in  the  operation  of  Mobile  IP.  Statistics  collected  from  this  controlled 
environment  will  then  be  used  as  a  nominal  “best-case”  benchmark.  As  such,  it  becomes 
crucial  to  architect  a  test  setup  that  is  as  “clean”  as  possible.  In  order  to  minimize  the 
introduction  of  unnecessary  “noise”  into  the  data,  a  minimalist  configuration  will  be 
adopted.  Thus,  all  unnecessary  services  will  be  turned  off  to  preclude  having  their 
resource  demands  skew  the  data. 

2.  Setting  up  the  IEEE  802.11  Wireless  Network  in  Infrastructure  Mode 
a.  Topological  Design 

Two  ESSs  will  be  configured  in  the  wireless  network  to  demonstrate  an 
ESS  transition,  in  which  Mobile  IP  is  required  to  provide  the  handoff.  A  single  BSS  will 
be  setup  within  each  ESS,  so  as  to  ensure  that  the  BSS  transition  will  also  correspond  to 
an  ESS  transition  (i.e.,  there  will  be  one  BSS  per  ESS).  This  will  minimize  any  potential 
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overhead  that  might  otherwise  result  when  a  wireless  mobile  node  encounters  a  BSS 
transition  within  an  ESS,  and  then  an  ESS  transition  when  it  roams  across  to  the  next 
ESS.  Put  another  way,  a  BSS  transition  will  force  an  ESS  transition  as  well. 

Because  of  the  close  proximity  of  the  entire  setup,  the  ESS  transition  will 
be  simulated  by  cutting  off  the  power  supply  to  one  of  the  access  points  serving  the  BSS- 
ESS  pair.  This  will  “force”  an  ESS  transition  to  take  place,  in  which  the  mobile  node  will 
have  to  reassociate  with  the  access  point  in  the  other  BSS-ESS  pair  in  order  to  continue 
its  data  transmission.  Figure  34  illustrates  such  a  wireless  network  that  will  be  setup. 
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Figure  34.  IEEE  802.1 1  Wireless  Network  in  Devised  Setup. 
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b.  Network  Service 

Table  9  lists  which  wireless  protocol  services  will  (and  will  not)  be 
utilized  during  the  data  collection.  As  previously  mentioned,  the  intent  will  be  to  only 
involve  essential  services  so  as  to  collect  the  “best  case”  data. 


Service 

Configured?  /  Used? 

Distribution 

Yes 

Integration 

Yes 

Association 

Yes 

Reassociation 

Yes 

Disassociation 

No 

Authentication 

Yes,  however,  setup  will  use  the  open-system  authentication  option. 

Deauthentication 

No 

Privacy 

No 

MSDU  Delivery 

Yes 

Table  9.  IEEE  802.1 1  Network  Services  Used  for  the  Devised  Setup. 


c.  Hardware  and  Software  Requirements 

Table  10  summarizes  the  list  of  hardware  and  software  that  will  be 
required  for  setting  up  the  IEEE  802.1 1  wireless  network. 


Component 

Description 

Hardware  Requirements 

Access  Point  1 

Linksys  Wireless  Network  Access  Point  (Model:  WAP1 1  ver.2.2) 

Access  Point  2 

Dell  TrueMobile  1170  Wireless  Base  Station  (Model:  WLGW201 1) 

Wireless  Network 
Interface 

Cisco  Aironet  340  series  1 1Mbps  Wireless  LAN  Adapter  (Model:  AIR- 
PCM340) 

Station  /  Mobile  Node 

Dell  Latitude  C640  laptop 

Software  Requirements 

Operating  System  for 
Station  /  Mobile  Node 

Microsoft  Windows  XP  Professional  Service  Pack  2  (with  driver  support 
for  Cisco  Aironet  340  series  1 1Mbps  Wireless  LAN  Adapter) 

Table  10.  Hardware  and  Software  Requirements  for  IEEE  802.1 1  Wireless  Setup. 


3.  Setting  up  the  Mobile  IP  Version  4  Network 
a.  Topological  Design 

A  home  network  and  two  foreign  networks  will  be  setup  and 
interconnected  to  form  a  Mobile  IP  network.  Each  network  is  serviced  by  a  router  that  is 
configured  with  the  corresponding  mobility  agent  service  to  function  either  as  a  home 
agent  or  foreign  agent.  A  correspondent  node  will  be  connected  to  the  home  network, 
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maintaining  ongoing  communications  with  the  mobile  node  in  order  to  demonstrate  the 
Mobile  IP  handoff  process  taking  place  while  a  mobile  node  is  still  in  the  process  of 
exchanging  data  in  a  connection-oriented  (TCP)  communication  session.  Figure  35 
depicts  the  Mobile  IP  network  that  will  be  setup. 
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Figure  35.  Mobile  IP  Version  4  Network  in  Devised  Setup. 


60 


b.  Network  Services 

To  minimize  any  unnecessary  network  traffic  and  exchanges,  services  that 
are  not  required  to  support  the  collection  of  the  performance  statistics  will  be  disabled. 
This  includes  the  configuration  of  static  routes  to  eliminate  exchanges  of  routing 
information  that  take  place  when  employing  dynamic  routing  protocols.  Table  11 
summarizes  the  list  of  network  services  that  will  be  configured  /  used  for  the  Mobile  IP 
network,  along  with  their  intended  purpose. 


Network  Service 

Purpose 

Mobile  IP  Services 

To  configure  the  appropriate  home  agent  or  foreign  agent  services  at 
the  respective  routers. 

Static  Routes 

To  enable  a  node  to  determine  the  path  for  data  delivery  from  the 
source  to  destination.  Static  routes  will  be  configured  to  minimize 
routing  exchanges  that  result  from  the  configuration  of  dynamic 
routing  protocols. 

DHCP  Service 

DHCP  service  is  enabled  at  the  home  agent  to  dynamically  assign  an 
IP  address  for  the  mobile  node  when  it  is  at  its  home  network. 

NTP  Service 

To  synchronize  the  time  among  the  home  agent  and  foreign  agents  to 
facilitate  Mobile  IP  registration,  as  well  as  data  collation. 

Table  11.  Network  Services  Configured  for  the  Mobile  IP  Version  4  Network  of  the 

Devised  Setup. 


c.  Hardware  and  Software  Requirements 

The  Mobile  IP  network  will  be  setup  using  Cisco  hardware  and  software. 
To  fully  support  the  operation  of  the  Mobile  IP  protocol,  the  version  of  the  Cisco 
Internetwork  Operating  System  (IOS)6  image  that  is  used  by  the  router  has  to  meet 
specific  software  requirements  [31].  Use  of  this  version  of  the  IOS  image;  however, 
places  certain  restrictions  on  the  type  of  Cisco  routers  that  can  be  deployed.  Table  12 
details  the  list  of  hardware  and  software  requirements  for  the  setup  of  the  Mobile  IP 
network. 


6  Cisco  IOS  image  functions  as  the  operating  system  for  all  Cisco  routers. 
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Component 

Description 

Hardware  Requirements 

Home  Agent 

Cisco  2621 XM  router  with  128MB  RAM  and  32MB  Flash 

Foreign  Agent  1 

Cisco  2651  XM  router  with  128MB  RAM  and  32MB  Flash 

Foreign  Agent  2 

Cisco  2651  XM  router  with  128MB  RAM  and  32MB  Flash 

Distribution  System 

CentreCOM  100Base-TX  IEEE  802.3  12-port  stackable  hub  (Model: 

MR912TX)  to  interconnect  the  3  routers 

Correspondent  Node 

Desktop  computer  with  Ethernet  network  interface 

Station  /  Mobile  Node 

Dell  Latitude  C640  laptop 

Software  Requirements 

Home  Agent 

Cisco  IOS  image  for  262 1XM  router  (with  Advanced  IP  Services)  version 
12.4.1a 

Foreign  Agent  1 

Cisco  IOS  image  for  2651XM  router  (with  Advanced  IP  Services)  version 
12.4.1a 

Foreign  Agent  2 

Cisco  IOS  image  for  2651XM  router  (with  Advanced  IP  Services)  version 
12.4.1a 

Correspondent  Node 

Operating  System:  Microsoft  Windows  2000  Professional  Service  Pack  4 
Tools/Utilities:  Netcat  listener  (for  data  transfer  via  TCP) 

Station  /  Mobile  Node 

Operating  System:  Microsoft  Windows  XP  Professional  Service  Pack  2 
Tools/Utilities:  Netcat  (for  data  transfer  via  TCP) 

Mobile  Node  Software:  Cisco  Mobile  Client  version  2.0.14 

Table  12.  Hardware  and  Software  Requirements  for  the  Mobile  IP  Network  Setup. 


C.  TEST  PLAN 

After  establishing  the  reference  architecture  for  setting  up  the  Mobile  IP  test 
environment,  this  section  will  deal  with  the  considerations  for  coming  up  with  the 
appropriate  test  cases  to  collect  the  performance  statistics  corresponding  to  the  Mobile  IP 
handoff  process. 

1.  Traffic  Considerations 

There  are  three  main  types  of  application  traffic  that  are  carried  by  IP,  namely, 
data,  voice  and  video.  Supporting  the  transmission  of  relatively  inelastic  (gaps  in  delivery 
are  problematic)  voice  and  video  traffic  over  IP  demands  much  more  performance  from 
the  underlying  network  than  does  the  transmission  of  elastic  static  data  (e.g.,  textual  files 
or  single  photos).  Quality  of  Service  (QoS)  [32]  mechanisms  are  required  to  guarantee  a 
certain  throughput  level  such  that  the  voice  and  video  traffic  can  be  transmitted  within  an 
acceptable  amount  of  network  delay  and  packet  loss. 

Adopting  a  minimalist  configuration  would  provide  the  necessary  quality  of 
service  that  is  required  to  support  voice  and  video  traffic,  since  the  network  bandwidth  in 
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this  setup  would  be  solely  dedicated  to  the  test  traffic  whose  performance  statistics  are 
being  measured.  Considering  that  most  voice  and  video  traffic  is  carried  over  UDP  (i.e.,  a 
connectionless  protocol  that  has  no  notion  of  “maintaining  a  session”)  [33],  a  decision  is 
necessary  regarding  what  type  of  traffic  to  use  during  testing.  One  obvious  option  is  to 
test  with  streaming  data  that  employs  a  connectionless  protocol  (i.e.,  employs  UDP).  The 
competing  option  is  to  test  with  non-streaming  data  that  employs  a  connection-oriented 
protocol  (i.e.,  employs  TCP).  The  latter  will  be  chosen  as  it  places  a  more  “stringent” 
demand  on  the  network  layer  to  maintain  a  session,  and  is  thus  the  better  choice  for 
conducting  the  Mobile  IP  handoff  test  cases.  In  order  to  demonstrate  that  session 
continuity  is  maintained  when  a  mobile  node  roams  from  one  network  to  another 
network,  data  will  be  transmitted  via  an  established  TCP  session  using  netcat.  The 
correspondent  node  will  initiate  a  netcat  listener  on  TCP,  and  the  mobile  node  will 
transmit  a  large  file  over  the  established  TCP  session  while  roaming  from  one  network  to 
the  other  network7. 

2.  Mobile  IP  Handoff  Considerations 

As  described  in  Chapter  2,  there  are  three  scenarios  in  which  a  Mobile  IP  handoff 
can  take  place;  namely,  when  a  mobile  node  leaves  its  home  network,  when  a  mobile 
node  roams  from  one  foreign  network  to  another  foreign  network,  and  when  a  mobile 
node  returns  to  its  home  network.  Since  the  Mobile  IP  setup  will  be  configured  based  on 
the  Cisco  IOS  mobility  services  and  Cisco  Mobile  Client  software,  the  products’  features 
will  have  to  be  taken  into  consideration  when  determining  the  handoff  scenarios  that  can 
be  implemented  in  this  setup. 

a.  Cisco  IOS  Mobility  Services 

Cisco  IOS  mobility  services  support  configuration  for  two  types  of  home 
networks:  physical  home  networks  and  virtual  home  networks  [5].  A  physical  home 
network  allows  a  mobile  node  to  attach  itself  directly  to  the  home  network;  in  which  case, 
all  Mobile  IP  functionality  for  the  mobile  node  will  become  inactive,  and  IP  traffic  will 
be  delivered  via  the  normal  routing  mechanisms.  The  disadvantage  with  the  use  of  the 

7  In  theory,  the  Mobile  IP  handoff  performance  results  should  be  identical  regardless  of  whether  the 
correspondent  node  or  the  mobile  node  initiates  the  data  transfer.  It  is  recommended  however,  that 
collecting  the  handoff  performance  results  for  the  scenario  where  the  correspondent  node  initiates  the  data 
transfer  to  the  mobile  node  be  considered  as  an  area  for  future  research. 
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physical  home  network  is  that  the  mobile  node  will  not  be  able  to  register  with  the  home 
agent  if  the  home  agent’s  network  interface  serving  the  physical  home  network  is  down. 

A  virtual  home  network  is  analogous  to  a  loopback  interface,  in  which  a 
virtual  network  will  always  be  available  and  not  susceptible  to  any  physical  failures. 
Virtual  home  networks  are  used  in  the  scenario  in  which  the  mobile  nodes  will  never  be 
physically  connected  to  the  home  networks.  Thus,  use  of  a  virtual  home  network  implies 
that  a  mobile  node  will  only  roam  from  foreign  network  to  foreign  network,  without  the 
need  for  it  to  return  to  its  home  network. 

b.  Cisco  Mobile  Client  Software 

Based  on  the  default  configuration  of  the  Cisco  Mobile  Client  software 
[34],  mobility  services  would  still  be  enabled  when  a  mobile  node  is  connected  to  its 
home  network.  In  this  scenario,  the  mobile  node  will  attempt  to  register  itself  with  the 
home  agent  using  a  co-located  care-of  address,  issued  by  the  DHCP  service  that  is 
configured  at  the  home  network.  Thus,  use  of  the  default  configuration  supports  the  use 
of  virtual  home  network,  where  the  mobile  node  at  its  home  network  is  treated  just  like 
any  other  foreign  network,  except  that  a  co-located  care-of  address  is  used  in  place  of  a 
foreign  agent’s  care-of  address. 

To  disable  all  mobility  services  when  the  mobile  node  is  connected  to  its 
home  network,  the  Cisco  Mobile  Client  software  offers  a  “pass-through”  mode,  in  which 
the  mobile  node  will  use  a  DHCP-advertised  item  to  detect  that  it  has  returned  to  its  home 
network.  In  this  scenario,  the  mobile  node  will  initiate  a  de-registration  process  with  its 
home  agent,  and  obtain  an  IP  address  assigned  by  the  home  network’s  DHCP  service. 
The  Cisco  Mobile  Client  will  cease  to  participate  in  the  delivery  of  IP  traffic,  handing 
over  the  responsibility  to  the  mobile  node’s  underlying  operating  system.  As  a  result, 
session  continuity  will  break  with  the  change  in  IP  address.  The  pass-through  mode  is 
typically  used  in  circumstances  in  which  triangle  routing  and  tunneling  are  not  desired. 
Thus,  use  of  the  pass-through  mode  work  hand-in-hand  with  the  notion  of  physical  home 
network;  the  only  disadvantage  being  the  disruption  in  session  continuity  when  a  mobile 
node  roams  away  from  home,  and  when  a  mobile  node  returns  home. 


64 


c.  Mobile  IP  Handoff  Test  Cases 

With  the  considerations  of  the  product  features  and  resulting  constraints 
described  in  the  previous  sections  and  summarized  in  Figure  36,  the  test  cases  that  will  be 
adopted  for  the  purpose  of  this  research  will  correspond  to  the  scenario  when  a  mobile 
node  roams  from  one  foreign  network  to  another  foreign  network.  The  scenarios  when  a 
mobile  node  roams  away  from  home  and  when  it  returns  home  will  not  be  used,  as  the 
way  in  which  these  are  implemented  deviate  from  RFC  3344’ s  recommendation  [4], 


Figure  36.  Considerations  Underlying  the  Use  of  Cisco  Mobile  IP  Products. 
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Figure  37  illustrates  the  test  procedure  for  carrying  out  the  Mobile  IP 
handoff  test  cases,  in  which  a  set  of  measurements  will  be  taken  for  the  handoff  occurring 
when  the  mobile  node  roams  from  foreign  network  1  to  foreign  network  2;  and  another 
set  of  measurements  taken  for  the  handoff  occurring  when  the  mobile  node  roams  from 
foreign  network  2  to  foreign  network  1 . 
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Figure  37.  Mobile  IP  Handoff  Test  Procedure. 
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3.  Care-of  Address  Considerations 

As  highlighted  in  Chapter  2,  Mobile  IP  supports  two  types  of  care-of  address: 
foreign  agent  care-of  address,  and  co-located  care-of  address.  The  Cisco  Mobile  Client 
software  offers  support  for  these  two  types  of  care-of  address  [34],  Table  13  outlines  the 
considerations  and  usage  scenarios  for  the  different  care-of  addresses. 


Care-of  Address 

Usage  Scenario 

Adopted  in  Test  Case? 

Co-located  Care- 
of  Address 

1.  Used  in  the  default  mode  when  a  mobile 
node  attempts  registration  with  its  home 
agent  when  it  is  at  its  home  network.  IP 
address  issued  by  the  DHCP  service 
configured  on  the  home  network  is  used 
as  the  co-located  care-of  address. 

1 .  No,  test  cases  are  based 
on  the  scenario  when  a 
mobile  node  roams  from  one 
foreign  network  to  another 
foreign  network. 

2.  Used  in  a  foreign  network,  in  which 
DHCP  service  is  enabled,  and  a  foreign 
agent  is  present.  The  mobile  node  will 
register  its  DHCP-assigned  address  as  the 
co-located  care-of  address  with  the  foreign 
agent. 

2.  No,  use  of  co-located  care- 
of  address  still  requires  the 
presence  of  a  foreign  agent. 

3.  Used  in  a  foreign  network  where  no 
foreign  agent  is  present.  Co-located  care- 
of  address  is  configured  statically  using  a 
locally  routable  address. 

3.  No,  co-located  care-of 
address  has  to  be  pre¬ 
configured.  Session 
continuity  will  break  when 
mobile  node  roams  from 
network  to  network. 

Foreign  Agent 
Care-of  Address 

Used  in  the  scenario  in  which  a  foreign 
agent  is  present  in  the  network  where  the 
mobile  node  is  visiting. 

Yes 

Table  13.  Considerations  and  Usage  Scenarios  for  Care-of  Addresses. 
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D.  DATA  COLLECTION  AND  COLLATION  METHODOLOGY 

Upon  identifying  the  test  cases  and  outlining  the  test  procedure,  data  collection 
and  collation  is  the  next  process  that  must  take  place  in  order  to  gather  the  performance 
statistics  for  the  Mobile  IP  handoff  process. 

1.  Candidates  for  Data  Collection 

As  mentioned  in  Chapter  2,  a  change  in  routing  to  facilitate  the  continued  delivery 
of  IP  traffic  to  the  mobile  node  is  considered  a  Mobile  IP  handoff;  the  process  involves 
move  detection  using  agent  discovery,  registration,  and  updating  of  the  routing 
information.  In  addition  to  using  agent  discovery  to  detect  that  the  mobile  node  has 
moved,  RFC  3344  [4]  states  that 

The  mobile  node  MAY  use  link-layer  mechanisms  to  decide  that  its  point 

of  attachment  has  changed. 

The  specific  link-layer  technology  that  is  appropriate  in  this  context  will  be  the 
IEEE  802.11  wireless  link- layer  handoff  mechanism  that  was  described  in  Chapter  3. 
Integrating  the  link-layer  handoff  mechanism  with  the  Mobile  IP  handoff  mechanism, 
Figure  38  illustrates  the  constituent  components  corresponding  to  the  handoff  process 
that  is  required  to  facilitate  an  IEEE  802. 1 1  wirelessly  connected  host  to  roam  from  one 
network  to  another  network. 
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17.  Receive  Registration 
Request  from  FA  &  Process: 
Authentication, 

Update  Mobility  Binding, 
Create  Tunnel, 

Delete  Old  Tunnel, 

Update  Route, 

Accept  Registration  Request 


c 

o 

'o 

JO 

'i— 

to 

b 


Registration  & 
Routing  Update 


ESS2 


Beacon 

Broadcast 


Access  Point  2 


2.  Probe  Request 


3.  Probe  Response 


4.  ACK 


Scanning 
5.  Authentication 


6.  ACK 


7.  Authentication 


8.  ACK 


Authentication 


Simulated  move  from 
foreign  network  1  to 
foreign  network  2. 


Wireless 
^  Y  Network 


Interface 


Legend: 

HA  -  Home  Agent 
FA  -  Foreign  Agent 


9.  Reassociation  Request 


10.  ACK 

11.  Reassociation  Response 

w 

Link  Layer 

12.  ACK 

w 

Handoff 

Association 

13.  Agent  Solicitation 

14.  Agent  Advertisement 

— ► 

Agent 

Discovery 


Mobile  IP 
Handoff 


15.  Registration  Request 

19.  Process  &  Forward 
Registration  Reply  to  Mobile  Node 
- ► 

Registration 


Figure  38.  Constituent  Components  for  the  Mobile  IP  Handoff  Process. 

2.  Data  Collection  Instrumentation 

To  facilitate  the  data  collection  process,  the  reference  architecture  derived  in  the 
earlier  section  of  this  chapter  was  instrumented  to  include  strategic  points  for  data 
collection.  Figure  39  depicts  the  resulting  instrumented  setup,  with  Table  14  detailing  the 
list  of  hardware  and  software  that  is  required  to  support  the  data  collection  process.  The 
detailed  component  configuration  for  the  instrumented  setup  can  be  found  in  Appendix  A 
of  this  report. 
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2.  Router  console  for  Home 
Agent  to  capture  Mobile  IP 
traffic  (reuse  Correspondent 


Correspondent  Node 
10.5.1.100  /24 


IP:  10.2.1.2  /24 
MAC:  00:06:25:54:b1:0f 
Wireless 
Network 
Interface 


IP:  10.4.1.2  /24 
MAC:  00:02:b3:94:39:62 
Wireless 
Network 
nterface 


Simulated  move  from 
foreign  network  1  to  foreign 
network  2  &  vice  versa 


Station/Mobile  Node  Station/Mobile  Node 

Home  Address:  10.10.10.1  /2<K - >  Home  Address:  10.10.10.1  /24 


1.  Kismet  in  Monitor  Mode  to 
capture  wireless  traffic 


Figure  39.  Mobile  IP  Setup  with  Data  Collection  Points. 
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Hardware 

Software 

Purpose 

Desktop  computer  with 
wireless  network  interface 
(in  monitor  mode) 

Kismet 

To  capture  wireless  traffic. 

Desktop  computer  (reuse 
Correspondent  Node) 

Hyper  Terminal  for 
router  console 

To  capture  Mobile  IP  traffic 
processed  by  the  Home  Agent. 

Laptop  computer  (reuse 
Mobile  Node) 

Hyper  Terminal  for 
router  console 

To  capture  Mobile  IP  traffic 
processed  by  Foreign  Agent  1 . 

Laptop  computer 

Hyper  Terminal  for 
router  console 

To  capture  Mobile  IP  traffic 
processed  by  Foreign  Agent  2. 

Desktop  computer  with 
Ethernet  network  interface 

Windump 

To  capture  Mobile  IP  traffic 
exchanged  among  the  3  routers. 

Table  14.  Hardware  and  Software  Requirements  for  Data  Collection. 

3.  Data  Collation 


Having  collected  the  data  using  the  instrumented  setup  described  in  the  previous 
section,  data  collation  must  take  place  in  order  to  assimilate  the  data  that  was  collected 
from  the  different  sources.  This  section  will  describe  the  specific  information  that  will  be 
collected  from  the  various  data  collection  points,  and  the  methodology  for  collating  all 
the  information  to  derive  the  performance  statistics  corresponding  to  the  constituent 
components  underlying  the  Mobile  IP  handoff  process. 

a.  Kismet 

Kismet  [35]  plays  a  crucial  role  in  the  entire  data  collection  process.  The 
IEEE  802.11  wireless  traffic  captured  by  Kismet  will  enable  one  to  delineate  the  link 
layer  handoff  components  from  the  Mobile  IP  handoff  components.  The  Kismet  output 
gives  a  rough  order  of  magnitude  for  the  time  taken  for  the  Mobile  IP  registration 
process.  The  identification  field  in  the  captured  registration  request  and  reply  message  is 
then  used  to  index  into  the  corresponding  home  agent  and  foreign  agent  router  debug  logs 
to  provide  a  finer  resolution  in  the  processing  of  the  registration  request  and  reply 
message  by  the  respective  routers.  Figure  40  shows  the  information  that  can  be  derived 
from  the  Kismet  output8,  along  with  the  methodology  for  computing  the  performance 
statistics  corresponding  to  the  constituent  components. 


Wireshark  Network  Protocol  Analyzer  [36]  was  used  to  analyze  the  dump  file  captured  by  Kismet. 
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1  2006-11-07  00:14:44.894900  10.5.1.100 

2  2006-11-07  00:14:49.312606  Aironet 38:82 :c9 

10.10.10.1  TCP  1234  >  1295  [ACK]  Seq=0  Ack=0  Win=1764Q  Len=0 

Li nksysG 54 : bl : Of  IEEE  8  Null  function  (No  data), SN=3 559, FN=0 

3  2006-11-07  00:14:49.323143  Inte l 94 : 39 : 62 

4  2006-11-07  00:14:49.424267  intel_94 : 39 : 62 

5  2006-11-07  00:14:49.525905  intel_94 :39:62 

6  2006-11-07  00:14:49.628153  intel_94 : 39 : 62 

7  2006-11-07  00:14:49.730900  intel_94 :39:62 

8  2006-11-07  00:14:49.800020  Aironet_38:82 :c9 

9  2006-11-07  00:14:49.801118  intel_94 :39:62 

10  2006-11-07  00:14:49.801356 

Broadcast  IEEE  8  Beacon  frame, SN=116, FN=0, BI=1Q0,  SSID:  "cs4910-L3" 

Broadcast  ieee  8  Beacon  frame,  sn=117,  fn=0,  bi=1Q0,  ssid:  " cs4 910-L3 

Broadcast  IEEE  8  Beacon  frame,  SN=118,  FN=0,  Bl=100,  Sr 

Broadcast  ieee  8  Beacon  frame,  sn=119,  fn=0,  bi=1Q0,  s  oCciimlng 

Broadcast  IEEE  8  Beacon  frame,  SN=120,  FN=0,  Bl=100,  SSj.-.  _ 

Broadcast  ieee  8  Probe  Request, sn=3560, fn=0,  ssid:  "cs4910-L3” 

Aironet_38:82 :c9  IEEE  8  Probe  Response, SN=3560, FN=0, Bl=100,  SSID:  "cs4910-L3" 
intel 94 :39:62  (RA  IEEE  8  Acknowledgement 

11  2006-11-07  00:14:50.917898  Aironet_38:82 :c9 

12  2006-11-07  00:14:50.918216 

13  2006-11-07  00:14:50.918851  intel_94 :39:62 

14  2006-11-07  00:14:50.919091 

lntel 94 : 39 : 62  IEEE  8  Authentication, SN=3 571, FN=0 

Aironet_38:82  :c9  (  ieee  8  Acknowledgement  Al  ithontinJltinn 

Aironet_38:82:c9  IEEE  8  Authentication,  SN=132,  FN=0  rtuiiiciiuuauuii 
intel 94 :39:62  (ra  ieee  8  Acknowledgement 

15  2006-11-07  00:14:50.920020  Aironet_38:82 :c9 

16  2006-11-07  00:14:50.920312 

17  2006-11-07  00:14:50.922530  intel_94 :39:62 

18  2006-11-07  00:14:50.922838 

intel_94 :39:62  IEEE  8  Reassociation  Request , SN=3 572, FN=0.  ssid:  "cs4910-L3" 

Aironet_38:82  :c9  (  IEEE  8  Acknowledgement  A 

Aironet_38:82 :c9  ieee  8  Reassociation  Response, sn=133, i  /\SSOCI3llON 
intel 94 :39:62  (RA  ieee  8  Acknowledgement 

19  2006-11-07  00:14:51.026621  10.10.10.1 

20  2006-11-07  00:14:51.033976  10.4.1.1 

21  2006-11-07  00:14:51.038404  10.10.10.1 

22  2006-11-07  00:14:54.077976  10.4.1.1 

23  2006-11-07  00:14:55.328737  10.10.10.1 

24  2006-11-07  00:14:55.510205  10.5.1.100 

224.0.0.2  ICMP  Router  solicitation 

255.255.255.255  ICMP  Mobile  IP  Advertisement 

10.4.1.1  Mobile  Reg  Request:  HAddr=10.10.10.1  COA=10.4.1.1 

10.10.10.1  Mobile  Reg  Reply:  HAddr=10.10.10.1,  code=0 

10.5.1.100  TCP  1295  >  1234  [ACK]  Seq=0  Ack=0  Win=65520  Len=1260 

10.10.10.1  TCP  1234  >  1295  [ACK]  Seq=0  Ack=1260  Win=17640  Len=0 

Type/subtype:  Null  function  (no  data)  (36) 

S)  Frame  control:  0x0948  (Normal) 

Duration:  314 

BSS  Id:  LinksysG_54:bl:0f  (00:06:25 : 54 :bl:0f) 

Source  address:  Aironet_38:82 :c9  (00:40:96:38:82 :c9) 
Destination  address:  LinksysG_54 :bl:0f  (00:06:25 : 54 :bl:0f) 
Fragment  number:  0 
Sequence  number:  3559 


No.  .  Time  Source 

1  2006-11-07  00:14:44.894900  10.5.1.100 

2  2006-11-07  00:14:49.312606  Aironet 38:82 :c9 

Destination  Protocol  Info 

10.10.10.1  TCP  1234  >  1295  [ACK]  Seq=0  Ack=0  win=17640  Len=0 

LinksvsG 54 :bl:0f  IEEE  8  Null  function  (no  data). SN=3 559, FN=0 

3  2006-11-07  00:14:49.323143  intel_94 : 39 : 62 

4  2006-11-07  00:14:49.424267  lntel_94 :39:62 

5  2006-11-07  00:14:49.525905  intel_94 : 39 : 62 

6  2006-11-07  00:14:49.628153  intel_94 :39:62 

7  2006-11-07  00:14:49.730900  lntel_94 :39:62 

8  2006-11-07  00:14:49.800020  Aironet_38:82 :c9 

9  2006-11-07  00:14:49.801118  intel_94 :39:62 

IQ  2QQ6-11-Q7  QQ;14 :49. 8Q1356 

Broadcast  ieee  8  Beacon  frame, sn=116, fn=Q, bi=10Q,  ssid:  "cs4910-L3" 

Broadcast  IEEE  8  Beacon  frame, SN=117, FN=0, BI=100,  SSID:  "cs4910-L3" 

Broadcast  ieee  8  Beacon  frame, SN=118, fn=0, bi=100,  S"  _ 

Broadcast  ieee  8  Beacon  frame,  sn=119,  fn=0,  bi=10Q,  :  00311111110 

Broadcast  IEEE  8  Beacon  frame, SN=120, fn=0, Bl=100,  s_ 

Broadcast  IEEE  8  Probe  Request , SN=3 560, FN=0,  SSID:  "cs4910-L3" 

Aironet_38:82 :c9  IEEE  8  Probe  Response, SN=3560, FN=0, Bl=100,  SSID:  "cs4910-L3" 
Intel  94 :39:62  (RA  IEEE  8  Acknowledgement 

11  2006-11-07  00:14:50.917898  Aironet_38:82 :c9 

12  2006-11-07  00:14:50.918216 

13  2006-11-07  00:14:50.918851  lntel_94 :39:62 

14  2006-11-07  00:1,4  :  50.  91909] 

intel_94 : 3 9 : 62  IEEE  8  Authentication, SN=3 571, FN=0 

Aironet_38:82 :c9  (  ieee  8  Acknowledgement  AnthAnti/'otiAn 

Aironet_38:82 :c9  IEEE  8  Authentication, SN=13 2, FN=0  MUin©nilC3llOn 
Intel  94:39:62  (RA  TFFF  8  Acknowledgement 

15  2006-11-07  00:14:50.920020  Aironet_38: 82: c9 

16  2006-11-07  00:14:50.920312 

17  2006-11-07  00:14:50.922530  lntel_94 : 39 : 62 

18  2006-11-07  00:14:50.922838 

- 19  2006-11-0/  00:14:51.026621  10.10.10.1 - 

intel_94 :39:62  ieee  8  Reassociation  Request, sn=3 572, fn=0,  ssid:  "cs4910-L3" 

Aironet_38:82 :c9  (  IEEE  8  Acknowledgement  . 

Aironet_38:82  :c9  ieee  8  Reassociation  Response,  sn=133,  ,SSOCI3tlOn 

intel_94 :39:62  (RA  IEEE  8  Acknowledgement 

— 224.0.0.2 - Icmp - Router  solicitation - 

20  2006-11-07  00:14:51.033976  10.4.1.1 

21  2006-11-07  00:14:51.038404  10.10.10.1 

22  2006-11-07  00:14:54.077976  10.4.1.1 

23  2006-11-07  00:14:55.32873710.10.10.1 

24  2006-11-07  00:14:55.510205  10.5.1.100 

255.255.255.255  ICMP  Mobile  IP  Advertisement 

10.4.1.1  Mobile  Reg  Request:  HAddr=10.1Q.10.1  coa=10.4.1.1 

10.10.10.1  Mobile  Reg  Reply:  HAddr=10.10.10.1,  code=0 

10.5.1.100  TCP  1295  >  1234  [ACK]  Seq=0  Ack=0  Win=65520  Len=1260 

10.10.10.1  TCP  1234  >  1295  [ACK]  seq=0  Ack=1260  win=17640  Len=0 

©  Frame  18  (24  bytes  on  wire,  24  bytes  captured) 

Q  IEEE  802.11 

Type/Subtype:  Acknowledgement  (29) 

0  Frame  control:  0x00D4  (Normal) 

Duration:  0 

Receiver  address:  lntel_94 : 39 : 62  (00:02 :b3 : 94 : 39 : 62) 

0010  c8  50  2d  4a  8^51*11*85™  ^  b3 

Frame  2  corresponds  to  the  last  frame  sent  by  Access  Point  1  (i.e. ,  BSS  ID:  00:06:25:54:b1 :0f)  prior  to  power 
shutdown.  Due  to  the  close  proximity  of  the  setup,  the  last  frame  received  by  the  wireless  mobile  node  from 
Access  Point  1  (in  a  real-world  scenario)  can  be  assumed  to  be  the  same  as  the  last  frame  transmitted  by 
Access  Point  1  prior  to  power  shutdown.  The  time  taken  for  the  constituent  components  of  the  link-layer 
handoff  is  thus  given  by: 

Scanning  =  Time  at  Frame  10  -  Time  at  Frame  2 
Authentication  =  Time  at  Frame  14  -  Time  at  Frame  10 
Association  =  Time  at  Frame  18  -  Time  at  Frame  14 
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No.  .  Time  Source  Destination  Protocol  Info 

1  2006-11-07  00:14:44.894900  10.5.1.100  10.10.10.1  TCP  1234  >  1295  [ACK]  Seq=0  Ack=0  Win=17640  l_en=0 

2  2006-11-07  00:14:49.312606  Aironet_38:82 :c9  LinksysG_54 :bl:0f  IEEE  8  Null  function  (No  data), SN=3559, FN=0 

3  2006-11-07  00:14:49.323143  lntel_94 :39:62  Broadcast  IEEE  8  Beacon  frame, sn-116, FN=0, Bl=100,  SSID:  "cs4910-L3" 

4  2006-11-07  00:14:49.424267  lntel_94 : 39 : 62  Broadcast  IEEE  8  Beacon  frame, SN=117, FN=0, BI=100,  SSID:  "cs4910-L3" 

5  2006-11-07  00:14:49.525905  lntel_94 : 39 : 62  Broadcast  IEEE  8  Beacon  frame, SN=118, FN=0, Bl=100,  SSID:  "cs4910-L3" 

6  2006-11-07  00:14:49.628153  lntel_94 : 39 : 62  Broadcast  IEEE  8  Beacon  frame, SN=119, FN=0, BI=100,  SSID:  "cs4910-L3" 

7  2006-11-07  00:14:49.730900  intel_94 : 39 : 62  Broadcast  IEEE  8  Beacon  frame, SN=120, FN=0, Bl=100,  SSID:  "cs4910-L3" 

8  2006-11-07  00:14 :49. 800020  Air onet_38: 82 :c9  Broadcast  IEEE  8  Probe  Request, SN=3560, FN=0,  SSID:  "cs4910-L3,, 

9  2006-11-07  00:14:49.801118  intel_94 : 39 : 62  Aironet_38:82 :c9  IEEE  8  Probe  Response, SN=3 560, FN=0, Bl=100,  SSID:  "cs4910-L3" 

10  2006-11-07  00:14:49.801356  lntel_94 : 39 : 62  (RA  IEEE  8  Acknowledgement 

112006-11-07  00:14 : 50. 917898  Air onet_38: 82 :c9  lntel_94 : 39 : 62  IEEE  8  Authentication, SN=3 571, FN=0 

12  2006-11-07  00:14:50.918216  Aironet_38:82 :c9  (  IEEE  8  Acknowledgement 

13  2006-11-07  00:14:50.918851  intel_94 :39:62  Aironet_38:82 :c9  IEEE  8  Authentication, SN=132, FN=0 

14  2006-11-07  00:14:50.919091  lntel_94 : 39 : 62  (RA  IEEE  8  Acknowledgement 

15  2006-11-07  00:14 : 50. 920020  Air onet_38: 82 :c9  lntel_94 : 39 : 62  IEEE  8  Reassociation  Request, SN=3572, FN=0,  SSID:  "cs4910-L3" 

16  2006-11-07  00:14:50.920312  Aironet_38:82 :c9  (  IEEE  8  Acknowledgement 

17  2006-11-07  00:14:50.922530  intel_94 : 39 : 62  Aironet_38:82 :c9  IEEE  8  Reassociation  Response, SN=133, FN=0 

18  2006-11-07  00:14:50.922838_ lntel 94  :39:62  (RA  IEEE  8  Acknowledgement 


19  2006-11-07  00:14:51.026621  10.10.10.1 

224.0.0.2 

ICMP  Router  solicitation  Aqent  Discovery 

20  2006-11-07  00:14:51.033976  10.4.1.1 

255.255.255.255 

ICMP  Mobile  IP  Advertisement  nycmuiouwcij 

21  Rpni«5tratinn  1  038404  lO-io.io.i 

22  .Ke9ISirail°n  ,4.077976  10.4.1.1 

10.4.1.1 

Mobile  Reg  Request:  HAddr=10. 10. 10. 1  COA=lG.4.1.1 

10.10.10.1 

Mobile  Rea  Reolv:  HAddr=10.10.1Q.l,  code=0 

23  2006-11-07  00:14:55.328737  10.10.10.1 

24  2006-11-07  00:14:55.510205  10.5.1.100 

10. 5.1.100 
10.10.10.1 

TCP  1295  >  1234  [ACK]  Seq=Q  Ack=0  Win=65520  Len=1260 

TCP  1234  >  1295  [ACK]  Seq=0  Ack=1260  win=17640  Len=0 

Message  Type:  Registration  Request  (1) 
i  Flags :  0x00 
Lifetime:  36000 

Home  Address:  10.10.10.1  (10.10.10.1) 

Home  Agent:  10.100.1.1  (10.100.1.1) 
care  of  Address:  10.4.1.1  (10.4.1.1) 
Identification:  Nov  7,  2006  00:14:54.1602  UTC 
i  Extensions 


TCP  traffic  continues 


0040  Qa  Oa  Oa  01  Oa  64  01  01  Oa  04  01  01  . d . mm 

0050  83  06  6d  6e  40  6e  70  73  20  14  00  00  HBB.  .mn  ®nps  ... 

0060  12  34  df  9a  4c  Ob  72  87  al  5e  95  d6  5f  f5  a6  6d  .4..L.r.  .a _ m 

0070  b5  e9 

Frame  19  to  frame  20  correspond  to  move  detection  using  agent  discovery.  Frame  21  to  frame  22  correspond 
to  the  Mobile  IP  registration  process.  Value  in  the  Identification  field  of  the  registration  request  /  reply  message 
is  used  to  index  into  the  respective  home  agent  and  foreign  agent  router  debug  logs  to  provide  a  finer 
resolution  of  the  registration  process.  The  time  taken  for  the  constituent  components  of  the  Mobile  IP  handoff 
is  thus  given  by: 

Move  Detection  using  Agent  Discovery  =  Time  at  Frame  21  -  Time  at  Frame  18 

The  time  taken  for  the  registration  process  and  update  in  routing  information  is  derived  from  the  data  collated 
at  the  router  logs. 


Figure  40.  Information  Derived  from  Kismet  Output. 


b.  Router  Debug  Log 

In  order  to  capture  the  Mobile  IP  traffic  that  is  processed  by  the  home 
agent  and  foreign  agent,  the  routers’  debug  mode  for  Mobile  IP  traffic  will  need  to  be 
enabled.  The  debug  traffic  that  will  be  generated  can  then  be  logged  using  Hyper 
Terminal’s  screen  capture  function. 

Each  handoff  test  case  requires  the  data  collation  from  two  router  logs; 
namely,  the  home  agent  router  log,  and  the  foreign  agent  router  log.  The  specific  foreign 
agent  router  log  to  use  depends  on  whether  the  mobile  node  is  roaming  from  foreign 
network  1  to  foreign  network  2,  or  from  foreign  network  2  to  foreign  network  1 .  If  the 
mobile  node  is  roaming  from  foreign  network  1  to  foreign  network  2,  the  appropriate 
foreign  agent  router  log  to  examine  will  be  that  of  foreign  agent  2’s  router  log,  since  the 
mobile  node  will  initiate  the  registration  process  with  its  home  agent  via  foreign  agent  2. 
Likewise  logic  can  be  applied  when  the  mobile  node  roams  from  foreign  network  2  to 
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foreign  network  1.  Figure  41  displays  the  collated  router  log  for  both  the  home  agent  and 
foreign  agent  when  the  mobile  node  roams  from  foreign  network  1  to  foreign  network  2. 


Router 

Nov  7 
Nov  7 
Nov  7 
Nov  7 

Nov  7 


10.4.1 


Debug  Log  of 

00:14:49.705 
00:14:49.705 
00 : 14 : 49 . 705 
00:14:49.705 

00:14:49.705 
1  HA  10.100.1 


Nov 

7 

00  : 14 : 49 . 705 

Nov 

7 

00:14:49.709 

Nov 

7 

00  : 14 : 49 . 709 

Nov 

7 

00:14:49.709 

Nov 

7 

00:14:49.709 

Router  Debug  Log  of 

Nov 

7 

00:14:49.715: 

Foreign  Agent  2 

MobilelP :  ParseRegExt  type  NAI(131)  addr  7C53ECC  end  7C53EEA 
ParseRegExt  skipping  6  to  next 

ParseRegExt  type  MHAE (32)  addr  7C53ED4  end  7C53EEA 
ParseRegExt  skipping  20  to  next 

FA  rev  registration  for  MN  mn@nps  on  FastEthernetO/1  using  COA 
1  lifetime  36000  options  sbdmg-t-  identification  C8FA4E7E2900296F 

MobilelP:  Registration  request  byte  count  =  82 
MobilelP:  FA  queued  MN  mn@nps  in  register  table 

MobilelP:  Visitor  registration  timer  started  for  MN  mn@nps,  lifetime  7 
MobilelP:  Adding  UDP  Tunnel  req  extension 

FA  forwarded  registration  for  MN  mn@nps  to  HA  10.100.1.1 


MobilelP 

MobilelP 

MobilelP 

MobilelP 


MobilelP: 


HomeAddr  10.10.10.1 
C8FA4E7E2900296F 


Nov 

7 

00:14:49.715: 

:  MobilelP 

Nov 

7 

00  : 14 : 49 . 715 : 

:  MobilelP 

Nov 

7 

00:14:49.715: 

:  MobilelP 

Nov 

7 

00:14:49.715: 

:  MobilelP 

Nov 

7 

00:14:49.715: 

:  MobilelP 

Nov 

7 

00:14:49.719: 

:  MobilelP 

Nov 

7 

00:14:49.719: 

:  MobilelP 

Nov 

7 

00 : 14 : 49 . 719 : 

:  MobilelP 

Nov 

7 

00:14:49.719: 

:  MobilelP 

Nov 

7 

00 : 14 : 49 . 719 : 

:  MobilelP 

Nov 

7 

00:14:49.719: 

:  MobilelP 

Nov 

7 

00:14:49.723: 

:  MobilelP 

Nov 

7 

00:14:49.723: 

:  MobilelP 

10.2 

.1. 

.1 

Nov 

7 

00:14:49.723: 

:  MobilelP 

Nov 

7 

00:14:49.727: 

:  MobilelP 

10.4 

.1. 

. 1  on  TunnelO 

Nov 

7 

00:14:49.731 

MobilelP 

Nov 

7 

00:14:49.731 

MobilelP 

Nov 

7 

00:14:52.731 

MobilelP 

Nov 

7 

00:14:52.731 

MobilelP 

Nov 

7 

00:14:52.731 

MobilelP 

Nov 

7 

00:14:52. 731 

MobilelP 

Nov 

7 

00:14:52.731 

MobilelP 

Nov 

7 

00:14:52. 731 

MobilelP 

Nov 

7 

00:14:52.731 

MobilelP 

Router  Debug  Log  of 

Foreign  A< 

Nov 

7 

00:14:52. 734 

MobilelP 

Nov 

7 

00:14:52.734 

MobilelP 

Nov 

7 

00:14:52. 734 

MobilelP 

Nov 

7 

00:14:52.734 

MobilelP 

Nov 

7 

00:14:52. 734 

MobilelP 

Nov 

7 

00:14:52.734 

Parsing  1 

Nov 

7 

00:14:52. 734 

MobilelP 

Nov 

7 

00:14:52.738 

MobilelP 

10.100. 

.1.1  lifetime 

36000 

Nov 

7 

00:14:52. 738 

MobilelP 

Nov 

7 

00:14:52.738 

MobilelP 

Nov 

7 

00:14:52. 738 

MobilelP 

Nov 

7 

00:14:52.738 

MobilelP 

Nov 

7 

00:14:52. 738 

MobilelP 

Nov 

7 

00:14:52.738 

MobilelP 

Nov 

7 

00:14: 52 .742 

MobilelP 

Home  Agent 

MobilelP:  HA  158  rev  registration  for  MN  mn@nps  on  FastEthernet0/0  using 
COA  10.4.1.1  HA  10.100.1.1  lifetime  36000  options  sbdmg-t-  identification 

NAT  not  detected  SRC: 10. 4. 1.1  COA:  10.4.1.1 
UDP  Tunneling  not  enabled 

Authenticating  MN  mn@nps  using  SPI  1234 
Authentication  algorithm  HMAC-MD5  and  16  byte  key 
Authentication  algorithm  HMAC-MD5  and  truncated  key 
Authentication  algorithm  HMAC-MD5  and  16  byte  key 
Authenticated  MN  mn@nps  using  SPI  1234  and  16  byte  key 
Name  for  local  pool  is  mn@nps 
Flow  10.10.10.1  already  exists 

Route  opt  bindupdate  entry  not  created:  No  SA  for  10.2.1.1 

Mobility  binding  for  MN  mn@nps  updated  -  tunnel  changed 
TunnelO  (IP/IP)  created  with  sre  10.100.1.1  dst  10.4.1.1 
MN  mn@nps  Delete  tunnel  route  10.10.10.1/255.255.255.255  via  gateway 


MN  mn@nps  Insert  route  for  10.10.10.1/255.255.255.255  via  gateway 


Stopping  LineProtoTimer  for  TunnelO 

swif  coming  up  TunnelO 

Roam  timer  started  for  MN  mn@nps  using  10.10.10.1, 

HA  accepts  registration  from  MN  mn@nps 

Dynamic  and  Static  Network  Extension  Length  0-0 
Composed  mobile  network  extension  length :0 
Authentication  algorithm  HMAC-MD5  and  16  byte  key 
MN  mn@nps  MHAE  added  to  MN  mn@nps  using  SPI  1234 

MN  mn@nps  -  HA  sent  reply  to  10.4.1.1 


lifetime  36000 


ParseRegExt  type  NAI(131)  addr  7C53108  end  7C5312E 
ParseRegExt  skipping  6  to  next 

ParseRegExt  type  MHAE (32)  addr  7C53110  end  7C5312E 
ParseRegExt  skipping  20  to  next 

ParseRegExt  type  UDPTUNREPE (44)  addr  7C53126  end  7C5312E 
DP  Tunnel  Reply  Extension  -  length  6 
ParseRegExt  skipping  6  to  next 

FA  rev  accept  (0)  reply  for  MN  mn@nps  on  FastEthernet0/0  using  HA 

Update  visitor  table  for  MN  mn@nps 
FA  route  add  10.10.10.1  successful.  Code  =  0 
Visitor  timer  started  for  MN  mn@nps,  lifetime  36000 
Reply  in  for  MN  mn@nps  using  10.10.10.1,  accepted 
registration  reply  byte  count  =  78 

FA  forwarding  reply  to  MN  mn@nps  (10.10.10.1  mac  0040 . 9638 . 82c9) 

FA  dequeued  MN  mn@nps  from  register  table 

Registration  ID  in  both  router  logs  matches  that  reflected  in  the  Kismet  output,  i.e.,  C8  FA  4E  7E  29  00  29  6F. 


Figure  41 .  Collated  Router  Logs  for  Home  Agent  and  Foreign  Agent. 
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c.  Windump 

Windump  [37]  is  used  to  capture  traffic  that  is  exchanged  among  the  home 
agent  and  foreign  agents.  Windump  plays  a  passive  role  in  the  data  collection  process.  It 
serves  to  validate  the  exchange  of  registration  request  and  reply  messages  that  occurred 
between  the  home  agent  and  foreign  agent.  In  addition,  the  output  from  Windump9  will 
demonstrate  that  IP  traffic  destined  for  the  mobile  node  is  indeed  tunneled  by  the  home 
agent  to  the  foreign  agent’s  care-of  address.  IP  traffic  originating  from  the  mobile  node  is 
delivered  via  normal  routing  mechanisms,  as  illustrated  in  Figure  42. 


Before  Handoff  Home  Agent  Foreign  Agent  1  Care-of 


No,  -  Time  Source 

Destination  Protoc 

)l  Info 

1  2006-11-07  00:14:44.608000  1Q.5.1.1G( 

)  10.10.10.1  TCP 

1234  >  1295  [ACK]  Seq=0  Ack=0  Win=17640  Len=0 

2  2006-11-07  00:14:50.750782  10.4.1.1 

10.100.1.1  Mobi 

le  Reg  Request:  HAddr=10.10.10.1  COA=10.4.1.1 

3  2006-11-07  00:14:53.783578  10. 100.1. 1 

10.4.1.1  Mobi 

le  Reg  Reply:  HAddr=10.10.10.1,  Code=0 

4  2006-11-07  00:14:55.045350  10.10.10.; 

10.5.1.100  TCP 

1295  >  1234  [ACK]  Seq=0  Ack=0  Wi n=65  520  Len=1260 

5  2006-11-07  00:14:55.224725  10. 5.1.10( 

)  10.10.10.1  TCP 

1234  >  1295  [ACK]  Seq=0  Ack=1260  Win=17640  Len=0 

@  Frame  1  (74  bytes  on  wire,  74  byl 

:es  captured) 

@  Ethernet  II,  src:  ci sco 9a : c9 : cfr 

r(00 :  Oe :  d7 :  9a :  c9 :  cO) ,  Dst  \\ 

rci sco ab : eO : aO  (00 : Oe : d7 : ab : eO : aO) 

@  internet  Protocol,  |src:  10.100.1.1  (10. 100. 1. 1)|,  jilt 7  10.2.1.1  (10.2.1.1)  IP  in  IP  Encapsulation 

+  internet  Protocol,  src:  1Q.5.1.1QQ  (10.5.1.100),  Dst:  1Q.1Q.1Q.1  (10.10.lQ.lj 


+  Transmission  control  Protocol,  src  Port:  1234  (1234),  Dst  Port:  1295  (1295),  seq:  0,  Ack :  0,  Len:  0 


No,  t  Time 


Source  Destination  Protocol  Info 


1  2006-11-07  00:14:44.608990  10.5.1.100 

10.10.10.1 

TCP 

1234  >  1295  [ACK]  Seq=0  Ack=0  Win=17640  Len=G 

2  2006-11-07  00:14 : 50. 750782  10.4.1.1 

10.100.1.1 

Mobile  Reg  Request:  HAddr=10.10.10.1  coa=1Q.4.1.1 

3  2006-11-07  00:14:53.783578  10.100.1.1 

10.4.1.1 

Mobile  Reg  Reply:  HAddr=10.10.10.1,  code=0 

4  2006-11-07  00:14:55.045355  10.10.10.1 

10.5.1.100 

TCP 

1295  >  1234  [ACK]  Seq=0  Ack=0  Wi n=65 520  Len=1260 

5  2006-11-07  00:14:55.224725  10.5.1.100 

10.10.10.1 

TCP 

1234  >  1295  [ACK]  Seq=0  Ack=1260  Win=17640  Len=0 

®  Flags:  0x00 

Lifetime:  36000 


Home  Address:  10.10.10.1  (10.10.10.1) 


ffi 


0000 

0010 

0020 

0030 

0040 

0050 

0060 


Home  Agent:  10.100.1.1  (10.100.1.1) 


care  of  Address:  10.4.1.1  (10.4.1.1) 


Identification:  Nov  7,  2006  00:14:54.1602  UTC 

Extensions 


00  Oe  d7  9a  c9  cO  00  Oe 

00  5a  19  be  00  00  ff  11 
01  01  01  b2  01  b2  00  46 
Qa  01  0a  64  01  01  0a  04 
EEMgj  83  06  6d  6e  40  6e 
df9a  4c  0b  72  87  al  5e 
90  06  00  00  00  04  00  00 


d7  a8  78  aO  08  00  45  cO 

8a  ab  0a  04  01  01  0a  64 

ce  3d  01  00  8c  aO  Oa  Oa 


01  01  _ 

70  73  20  14  00  00  12  34 
95  d6  5f  f 5  a6  6d  b5  e9 


Registration  ID  matches  that 
reflected  in  Kismet  output,  Home 
Agent  &  Foreign  Agent  router  log. 


No,  -  Time  Source 

Destination 

Protocol  Info 

1  2006-11-07  00:14:44.608550  10.5.1.100 

10.10.10.1 

TCP  1234  >  1255  | 

[ack; 

|  seq=0  Ack=0  win=17640  Len=0 

2  2006-11-07  00:14:50.755782  10.4.1.1 

10.100.1.1 

Mobile  Reg  Request: 

HAddr =10.10.10.1  COA=10. 4 .1.1 

3  2006-11-07  00:14:53.783578  10.100.1.1 

10.4.1.1 

Mobile  Reg  Reply:  HAddr= 

=10.10.10.1,  Code=0 

I  4  2006-11-07  00:14:55.04535510.10.10.1 

10.5.1.100 

TCP  12y5  >  1234 

ACK 

Seq=0  Ack=0  Win=6552Q  Len=1260 

5  2006-11-07  00:14:55.224725  10.5.1.100 

10.10.10.1 

TCP  1234  >  1255 

;ack; 

Seq=0  Ack=1260  Win=17640  Len=0 

0  Frame  4  (1314  bytes  on  wire,  1314  bytes  captured) 

m  Ethernet  n.  src:  cisco  a8:78:a0  (00:0e:d7:a8:78:a0). 

Dst : 

:  cisco  9a:c9:c0 

(QQ:0e:d7:9a:c9:cQ) 

0  internet  Protocol,  src:  10.10.10.1 

(10.10.10.1),  Dst : 

10. 5.1.100  (10. 5.1.100) 

0  Transmission  Control  Protocol,  Src 

Port:  1295  (1295), 

Dst 

Port:  1234  (1234),  Seq:  0>Ack:  0,  Len:  1260 

Data  (1260  bytes) 


IP  traffic  from  mobile  node  delivered 
via  normal  routing  mechanism 


9  Wireshark  Network  Protocol  Analyzer  [36]  was  used  to  analyze  the  dump  file  captured  by  Windump. 
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After  Handoff  Home  Agent  Foreign  Agent  2  Care-of 


No,  t  Time  Source 

Destination 

Protocol  Info 

1  2006-11-07  00:14:44.608500  10.5.1 

100  10.10.10.1 

TCP  1234  >  1255  [ACK]  Seq=0  Ack=0  Win=17640  Len=0 

2  2006-11-07  00:14:50.755782  10.4.1 

1  10.100.1.1 

Mobile  Reg  Request:  HAddr=10.10.10.1  COA=10.4.1.1 

8  2006-11-07  00:14:58.788578  10.100 

1.1  10.4.1.1 

Mobile  Reg  Reply:  HAddr=10.10.10.1,  code=0 

4  2006-11-07  00:14:55.045855  10.10.: 

.0.1  10.5.1.100 

TCP  1255  >  1234  [ACK]  Seq=0  Ack=0  Win=65520  Len=1260 

5  2006-11-07  00:14:55.224725  10.5.1 

TUfi  10.10.10.1 

TCP  1234  >  1255  LACK]  Seq=Q  Ack=1260  Win=1764Q  Len=Q 

+  Frame  5  (74  bytes  on  wire,  74  by 

:es  captured) 

i+i  Ethernet  II,  src:  cisco 9a:c9:cft 

r(00:0e:d7:9a:c9:c0),  Dst n 

rci sco a8 : 78 : aO  (00 : Oe : d7 : a8 : 78 : aO) 

+  internet  Protocol  ,|  src :  10.100.1.1  (10.100.1.1),||dst  :  10.4.1.1  (10.4.1.1)  |  IP  in  IP  Encapsulation 

l+l  internet  Protocol,  src:  10.5.1.100  (10.5.1.100),  Dst :  10.10.10.1  (10.10.10.1) 

+  Transmission  control  Protocol,  src  Port:  1234  (1234),  Dst  Port:  1295  (1295),  seq:  0,  Ack :  1260,  Len:  0 

Figure  42.  Windump  Output. 


4.  Putting  Everything  Together 

With  the  knowledge  of  how  the  performance  statistics  for  the  constituent 
components  corresponding  to  the  handoff  process  will  be  measured,  Figure  43 
summarizes  the  data  collection  and  collation  methodology  that  will  be  adopted  for  the 
purpose  of  this  research. 

As  indicated  in  Figure  43,  there  is  an  inherent  limitation  in  which  the  time  of 
transmission  from  the  mobile  node  to  the  foreign  agent;  and  the  time  of  transmission 
from  the  foreign  agent  back  to  the  mobile  node,  could  not  be  measured  using  the  existing 
instrumentation.  Since  transmission  of  the  RF  signal  travels  approximately  at  the  speed  of 
light,  subjected  to  some  variability  with  temperature,  pressure  and  humidity  conditions 
and  the  distances  are  very  short  (several  meters  at  most),  the  time  of  transmission  for 
these  two  scenarios  is  negligible  and  will  be  ignored  when  computing  the  performance 
statistics  for  the  Mobile  IP  handoff  process. 
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17.  Receive  Registration 
Request  from  FA  &  Process: 
Authentication, 

Update  Mobility  Binding, 
Create  Tunnel, 

Delete  Old  Tunnel, 

Update  Route, 

Accept  Registration  Request 


0.  Last  Frame  sent  by  Access  Point  1 


2.  Probe  Request 


◄ — 

3.  Probe  Response 

4.  ACK 

Scanning 

5.  Authentication 

6.  ACK 

7.  Authentication 

w 

◄ - 

8.  ACK 

w 

3.  Router  console  for 
Foreign  Agent  2  to 
capture  Mobile  IP  traffic 
steps  16,  18  &  19 


Legend: 

HA  -  Home  Agent 
FA  -  Foreign  Agent 


Simulated  move  from 
foreign  network  1  to 
foreign  network  2 


Wireless 
^  Y  Network 


Interface 


Mobile  IP 
Handoff 


Authentication 


9.  Reassociation  Request 
10.  ACK 
11.  Reassociation  Response 
12.  ACK 


Association 


13.  Agent  Solicitation 

14.  Agent  Advertisement 

Agent 
Discovery 

1 .  Kismet  inHVIonitor  Mode  to 
capture  wireless  traffic  - 

15.  Registration  Request  steps  0-15 

19.  Process  &  Forward 
Registration  Reply  to  Mobile  Node 


Registration 


Figure  43.  Summary  of  the  Data  Collection  and  Collation  Methodology. 
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V.  RESULTS  AND  FINDINGS 


A.  INTRODUCTION 

Using  the  Mobile  IP  test  setup  and  data  collection  and  collation  methodology 
described  in  Chapter  4,  a  total  of  63  test  cases  were  carried  out  to  gather  the  performance 
statistics  relating  to  the  Mobile  IP  handoff  process.  The  chapter  will  present  a  summary 
of  the  performance  statistics  that  were  derived  for  the  constituent  components  underlying 
the  Mobile  IP  handoff  process.  After  which,  we  will  give  an  analysis  of  the  results 
obtained  and  recommend  the  types  of  applications  that  Mobile  IP  can  support.  Finally, 
we  conclude  the  chapter  by  briefly  discussing  the  components  of  the  handoff  process  that 
can  potentially  be  exploited  by  attackers  intent  on  delaying  or  denying  the  handoff 
service. 


B.  MOBILE  IP  HANDOFF  PERFORMANCE  STATISTICS 

Out  of  the  63  test  cases  that  were  conducted,  31  of  them  correspond  to  the 
scenario  where  the  mobile  node  roams  from  foreign  network  1  to  foreign  network  2;  and 
the  remaining  32  correspond  to  the  scenario  where  the  mobile  node  roams  from  foreign 
network  2  back  to  foreign  network  1.  The  performance  statistics  for  the  constituent 
components  underlying  the  Mobile  IP  handoff  process  in  each  scenario  were  tabulated 
and  averaged  over  the  number  of  test  cases  that  were  conducted.  Figure  44  shows  the 
results  that  were  obtained  for  the  scenario  where  the  mobile  node  roams  from  foreign 
network  1  to  foreign  network  2;  and  Figure  45  shows  the  corresponding  results  for  the 
scenario  where  the  mobile  node  roams  from  foreign  network  2  back  to  foreign  network  1 . 
The  results  for  the  individual  test  cases  can  be  found  in  Appendix  B  of  this  report. 
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Figure  44.  Mobile  IP  Handoff  Performance  Statistics  for  Roaming  from  Foreign 

Network  1  to  Foreign  Network  2. 
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Figure  45.  Mobile  IP  Handoff  Performance  Statistics  for  Roaming  from  Foreign 

Network  2  to  Foreign  Network  1 . 
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C.  RESULTS  ANALYSIS 

Using  the  results  that  were  described  in  the  previous  section,  a  component 
analysis  was  performed  to  evaluate  the  performance  statistics  for  the  three  main 
components  constituting  the  Mobile  IP  handoff,  namely,  move  detection  using  link  layer 
handoff  and  agent  discovery,  registration  and  updating  of  routing  information. 

1.  Registration  and  Routing  Update 

The  “Registration  and  Routing  Update”  component  appears  to  be  the  main  cost 
driver  for  the  Mobile  IP  handoff  process.  The  standard  deviation  for  this  component  is 
very  low,  having  only  a  value  of  0.002;  implying  that  the  average  time  computed  for  the 
registration  and  routing  update  process  is  fairly  accurate  with  little  variance. 

Further  analysis  of  the  subcomponents  underlying  the  “Registration  and  Routing 
Update”  component  reveals  the  pre-processing  by  the  home  agent  prior  to  accepting  the 
registration  request  (i.e.,  the  “Home  Agent  Accepts  Registration  Request  and  Sends 
Registration  Reply”  subcomponent)  to  be  the  main  contributor  of  the  overall  processing 
delay.  Since  the  time  measurement  for  this  subcomponent  is  already  at  its  “atomic”  level, 
with  the  router  debug  log  offering  no  further  breakdown  in  processing  of  this 
subcomponent,  one  would  probably  need  to  examine  the  IOS  software  that  is  written  for 
the  Mobile  IP  registration  processing  in  order  to  fine-tune  the  performance  parameters. 

2.  Move  Detection  Using  Link  Layer  Handoff 

The  next  contributor  to  the  processing  delay  of  the  Mobile  IP  handoff  process  is 
the  “Link  Layer  Handoff’  component  that  is  used  for  move  detection.  It  was  observed 
that  the  link  layer  handoff  performance  was  roughly  100%  faster  for  the  scenario  where 
the  mobile  node  roams  from  foreign  network  2  to  foreign  network  1,  compared  to  the 
scenario  where  the  mobile  node  roams  from  foreign  network  1  to  foreign  network  2.  The 
unintentional  use  of  different  brand/model  of  access  points  for  the  two  foreign  networks 
has  led  to  the  variability  of  the  data  that  was  collected  for  the  two  handoff  scenarios. 

Further  analysis  of  the  performance  statistics  for  the  “Link  Layer  Handoff’ 
subcomponents  seemed  to  indicate  that  the  scanning  process  was  the  main  cause  for  the 
variance  in  the  two  sets  of  readings.  As  the  same  wireless  adaptor  was  used  for  the 
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mobile  node,  an  obvious  deduction  is  that  the  default  scanning  parameters10  used  for  the 
access  point  in  foreign  network  1  outperformed  those  used  for  the  access  point  in  foreign 
network  2.  Thus,  the  scanning  parameters  for  the  access  point  in  foreign  network  2  could 
potentially  be  fine-tuned  for  better  performance 1 1 . 

The  standard  deviation  for  the  “Link  Layer  Handoff ’  component  is  higher  than 
the  computed  average  for  both  the  scenarios.  The  high  deviation  value  could  possibly  be 
attributed  to  the  nature  of  the  wireless  medium,  which  is  unreliable  and  highly  susceptible 
to  noise  and  interference  from  the  surrounding  environment.  Considering  the  constraints 
of  space  and  the  physical  location  where  the  test  cases  were  conducted,  RF  interference 
from  the  neighboring  equipment  could  possibly  have  affected  the  readings. 

3.  Move  Detection  Using  Agent  Discovery 

The  third  contributor  of  the  processing  delay  for  the  Mobile  IP  handoff  process  is 
the  “Agent  Discovery”  component  used  for  move  detection.  A  similar  observation  was 
made  for  the  performance  of  this  component,  in  that  the  results  for  the  scenario  when  the 
mobile  node  roams  from  foreign  network  2  to  foreign  network  1  were  better  than  the 
scenario  when  the  mobile  node  roams  from  foreign  network  1  to  foreign  network  2. 

As  the  exchange  of  agent  solicitation  and  agent  advertisements  in  the  agent 
discovery  process  takes  place  via  the  access  point,  one  could  reasonably  deduce  that  the 
default  control  parameters  for  the  channel  acquisition  and  carrier-sensing  maintenance 
functions  differ  for  the  two  access  points,  and  could  be  adjusted  accordingly12.  In 
addition,  the  standard  deviation  derived  for  the  “Agent  Discovery”  component  is  higher 
than  its  computed  average,  the  reason  for  this  could  possibly  be  attributed  to  the 
unreliable  nature  of  the  wireless  medium,  as  described  in  the  preceding  section. 


10  It  was  the  intent  of  this  thesis  research  to  use  the  default  parameters  for  the  IEEE  802.1 1 -compliant 
access  points  so  as  to  gather  a  set  of  readings  that  could  be  used  as  baseline  for  performance  fine-tuning. 

1 1  The  scanning  parameters  can  only  be  fine-tuned  if  the  specific  access  point  provides  an  option  for 
changing  such  parameters.  Otherwise,  the  fine-tuning  can  only  take  place  at  the  time  of  manufacture  of  the 
access  point. 

12  Again,  these  control  parameters  can  only  be  adjusted  if  the  access  point  has  made  provisions  for 
changing  such  settings. 
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4.  Candidates  for  Performance  Fine-tuning 

Having  analyzed  the  performance  statistics  for  the  constituent  components 
underlying  the  Mobile  IP  handoff  process,  Table  15  provides  a  summary  of  the 
parameters  that  are  potential  candidates  for  performance  fine-tuning. 


Mobile  IP  Handoff 
Component 

Applicable  in  which 
Roaming  Scenario? 

Subcomponent/ 

Parameter 

Suggested  Improvements 

Registration  & 

Routing  Update 

Foreign  network  1  to  2  & 
Foreign  network  2  to  1 

Home  Agent  Accepts 
Registration  Request 
&  Sends  Registration 
Reply  subcomponent 

Examine  the  router  IOS  software 
that  is  handling  the  registration 
processing  for  possible  code 
optimization  so  as  to  improve  the 
performance  for  this  component. 

Link  Layer  Handoff 

Foreign  network  1  to  2 

Scanning  parameters 

Adjust  the  scanning  parameters  of 
the  access  point  in  foreign  network 

2  to  match  those  of  the  access 
point  in  foreign  network  1  (if  it  is 
feasible).  Otherwise,  use  the  same 
brand/model  as  the  access  point  in 
foreign  network  1. 

Agent  Discovery 

Foreign  network  1  to  2 

Control  parameters  for 
channel  acquisition 
and  carrier-sensing 

Adjust  the  control  parameters  of 
the  access  point  in  foreign  network 

2  to  match  those  of  the  access 
point  in  foreign  network  1  (if  it  is 
feasible).  Otherwise,  use  the  same 
brand/model  as  the  access  point  in 
foreign  network  1. 

Table  15.  Summary  of  Potential  Candidates  for  Performance  Fine-tuning  for  the  Mobile  IP 

Handoff  Process. 
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D.  APPLICATION  SUPPORT 


After  analyzing  the  performance  statistics  for  the  Mobile  IP  handoff  process  to 
support  the  roaming  of  an  IEEE  802.1 1  wirelessly  connected  host,  it  is  appropriate  at  this 
juncture  to  examine  the  different  types  of  traffic  requirements  in  order  to  determine  the 
applications  that  can  be  supported  by  Mobile  IP. 

1.  Data 

As  described  in  Chapter  4,  the  test  cases  were  conducted  based  on  data 
transmission  over  an  established  TCP  session,  so  as  to  demonstrate  that  the  session 
continuity  is  indeed  maintained  when  the  mobile  node  roams  from  one  foreign  network  to 
another  foreign  network.  Since  Mobile  IP  was  shown  to  support  data  transmission  of 
connection-oriented  TCP  traffic,  which  places  a  more  “stringent”  requirement  on  the 
network  layer  in  order  to  maintain  a  session;  Mobile  IP  should  have  no  problems 
supporting  connectionless  protocols  such  as  UDP.  As  a  result,  a  variety  of  applications 
that  utilize  either  TCP  or  UDP  as  the  underlying  transport  protocol,  and  which  are  not 
time-sensitive  in  nature,  can  be  supported  by  Mobile  IP. 

2.  Voice 

To  support  voice  requirements,  the  International  Telecommunication  Union  (ITU) 
has  recommended  a  set  of  values  for  the  maximum  round  trip  delay  that  can  be  tolerated 
by  a  voice  system,  and  the  perceived  quality  of  the  voice  channel  at  these  values  [38]. 
Table  16  lists  the  recommendations  that  are  defined  in  ITU-T  G.l  13. 


G.113  Delay  Specification 

0  to  150  msec 

acceptable  to  most  applications 

150  to  400  msec 

acceptable  for  international  connections 

>  400  msec 

acceptable  for  public  network  operation 

Table  16.  ITU-T  G.l  13  Delay  Specification  for  Voice  System  (From:  Ref.  [38]). 

In  addition  to  the  ITU-T  G.l  13  Voice  Quality  Specification  shown  in  Table  16, 
ITU-T  G.l  14  recommends  an  end-to-end  delay  of  not  more  than  150  milliseconds  for 
good  voice  quality  [39].  As  depicted  in  Figure  46;  however,  there  are  scenarios  in  which 
an  end-to-end  delay  of  more  than  150  milliseconds  will  be  encountered.  Although  the 
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ITU-T  G.114  recommendation  would  categorize  such  delays  as  being  outside  the 
acceptable  range  of  voice  quality,  many  conversations  occur  daily  over  satellite  links  that 
consistently  exceed  the  150  millisecond  limit  due  to  the  distance  (-22,300  miles)  of 
geosynchronous  satellites  above  the  Earth's  surface.  We  cannot  establish  a  hard  upper 
limit  on  "acceptable"  delay  as  voice  quality  is  also  subjectively  based  on  what  an 
individual  user  will  accept  and  use. 


CB  Zone 


Satellite  Quality 

High  Quality 

Fax  Relay,  Broadcast 

i . 

t  1  1  1  1  1  1  t, 

0  100  ^ 

J  I  1  S  I  1  1  1  !  1  I  S  S  1  1  1  1  S  1  I  S  S  S  I  1  S  1  3  1  8  8  1 

f  200  300  400  500  600  700  30 

Tims  (msec) 
Delay  Target 


Figure  46.  End-to-End  Delay  in  ITU-T  G.l  14  Specification  (From:  Ref.  [39]). 

Given  the  recommended  values  that  are  reflected  in  Table  16  and  Figure  46,  it 
will  be  optimal  to  keep  the  maximum  round  trip  delay  to  less  than  150  milliseconds  to 
support  most  voice  applications  and  maintain  a  consistent  level  of  good  voice  quality. 
Tests  conducted  by  the  University  of  Maryland  indicated  that  an  access  point  probe 
occurs  every  250  to  400  milliseconds  [38],  These  values  match  the  computed  average  that 
was  obtained  from  the  Mobile  IP  handoff  test  cases  conducted  for  the  scenario  when  the 
mobile  node  roams  from  foreign  network  2  to  foreign  network  1:  the  scanning 
subcomponent  of  the  link  layer  handoff  took  0.250  seconds.  It  is  apparent  that  the 
scanning  subcomponent  alone  has  already  exceeded  the  maximum  round  trip  delay  that 
can  be  tolerated  by  most  voice  applications.  An  ongoing  effort  to  improve  the 
performance  of  the  link  layer  handoff  in  a  wireless  environment  is  currently  addressed  by 
the  IEEE  802.1  le  (QoS)  task  group  [40], 

After  addressing  the  performance  issue  relating  to  the  link  layer  handoff,  the 
Mobile  IP  protocol  will  need  to  provide  support  for  the  proper  handling  of  QoS  related 
traffic  at  its  mobility  agents  and  intermediate  nodes,  so  that  QoS  sensitive  IP  services  can 


86 


be  supported  over  Mobile  IP.  RFC  3583  [41]  describes  the  requirements  for  an  IP  QoS 
mechanism  for  its  satisfactory  operation  with  Mobile  IP,  and  recommends  that 

The  expectation  is  that  the  appropriate  working  group  will  use  this 

requirements  document  to  provide  a  QoS  solution  for  Mobile  IP. 

Therefore,  both  the  IEEE  802.11  link  layer  handoff  performance  and  Mobile  IP’s 
support  for  QoS  traffic  will  need  to  be  addressed,  before  the  Mobile  IP  handoff  process 
can  be  used  to  support  the  roaming  of  an  IEEE  802. 1 1  wirelessly  connected  host  that  is 
supporting  voice  applications. 

3.  Video 

Video  applications  can  be  categorized  into  two  main  types:  interactive  video 
applications  such  as  videoconferencing,  and  “store-and-forward”  video  applications  such 
as  video  streaming.  According  to  [42],  real-time  IP  applications  such  as 
videoconferencing  and  voice-over-IP  have  an  upper  bound  end-to-end  latency 
requirement  of  not  more  than  150  milliseconds.  Thus,  the  same  voice  requirements  that 
were  described  in  the  preceding  section  will  apply  in  order  for  Mobile  IP  to  be  able  to 
support  interactive  video  applications. 

On  the  other  hand,  video  streaming  applications  demand  a  less  stringent 
requirement  on  the  end-to-end  network  delay.  Depending  on  the  application’s  buffering 
capabilities,  “non-interactive”  video  content  can  be  pre-downloaded  and  stored  in  the 
application’s  buffer  prior  to  playback.  Such  a  mechanism  will  “convert”  the  real-time 
requirement  to  a  non  real-time  one;  treating  video  streaming  just  like  any  other 
transmission  of  elastic  static  data.  Thus,  Mobile  IP  should  have  no  problems  supporting 
non-interactive  video  streaming  applications. 


E.  SECURITY  RAMIFICATIONS 

The  implementation  of  security  measures  often  comes  at  the  cost  of  performance. 
In  architecting  the  Mobile  IP  setup  to  gather  performance  statistics  for  the  constituent 
components  underlying  the  handoff,  minimal  security-related  services  were  configured 
for  both  the  IEEE  802.1 1  wireless  network  and  Mobile  IP  network.  As  a  recap,  Table  17 
shows  the  security-related  services  that  were  enabled  for  the  setup. 
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Service 

Configured?  /  Used? 

IEEE  802.11  Security-Related  Services 

Authentication 

Open-system  authentication  was  configured. 

Privacy 

No 

Mobile  IP  Security-Related  Services 

Authentication  Extension 

The  Mobile-Home  Authentication  Extension  (MHAE)  was  configured. 

Reverse  Tunneling 

No 

Table  17.  Security- Related  Services  Configured  for  the  Mobile  IP  Setup. 


The  Mobile  IP  setup,  in  its  most  primitive  configuration,  can  be  exploited  by  an 
attacker  intent  on  denying  or  delaying  proper  handoff  service.  Specifically,  the  following 
section  will  describe  the  handoff  components  that  are  potentially  vulnerable  to  attacks 
launched  by  a  malicious  user. 

1.  Link  Layer  Handoff 

Link  layer  handoff  comprises  mainly  the  scanning,  authentication  and  association 
subcomponents.  The  use  of  the  default  authentication  protocol,  i.e.,  open  system 
authentication,  for  the  IEEE  802. 1 1  wireless  network  that  was  setup  essentially  offers  no 
authentication,  as  there  is  no  control  over  who  can  associate  with  the  access  point  [26]. 
Thus,  any  malicious  user  can  potentially  exploit  the  “identification  and  authentication 
vulnerability”  to  gain  unauthorized  access  to  the  wireless  network  that  is  served  by  the 
access  point. 

The  management  frames  that  are  used  in  the  link  layer  handoff  process  do  not 
offer  any  form  of  integrity  protection.  Coupled  with  the  fact  that  link  layer  MAC 
addresses  can  be  easily  forged,  an  attacker  can  potentially  launch  a  man-in-the-middle 
attack  [26]  against  the  IEEE  802. 1 1  wireless  network,  as  illustrated  in  Figure  47. 
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Wireless 


la.  Establishes  rogue  access 
point  with  same  SSID  and  MAC 
address  as  another  valid  access 
point  but  on  a  different  channel. 

Figure  47.  Example  Man-in-the-Middle  Attack  for  the  IEEE  802.1 1  Wireless 

Network  (After:  Ref.  [26]). 


Exploiting  the  “lack  of  integrity  protection  vulnerability”  of  the  management 
frames,  denial-of-service  attacks  can  also  be  launched  against  the  IEEE  802. 1 1  wireless 
network  [26],  Figure  48  and  Figure  49  illustrate  two  possible  denial-of-service  attacks 
that  can  be  launched  by  an  attacker. 
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Figure  48. 


Attacker  Station 

Denial-of-Service  Attack  Using  Deauthenticaton  /  Disassociation  Frame. 


Valid  Station 


Figure  49.  Denial-of-Service  Attack  Using  Resource  Exhaustion. 
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2.  Agent  Discovery 

As  described  in  Chapter  2,  RFC  3344  [4]  requires  that  all  the  registration 
messages  between  the  mobile  node  and  its  home  agent  be  authenticated.  Because  of  key 
management  challenges,  registration  messages  relayed  by  the  foreign  agent  will  only  be 
authenticated  if  an  optional  mobility  security  association  exists  between  the  mobile  node 
and  foreign  agent;  and  if  an  optional  mobility  security  association  exists  between  the 
foreign  agent  and  home  agent.  This  is  a  potential  vulnerability  that  can  be  exploited  by  an 
attacker  to  launch  a  denial-of-service  or  traffic  redirection  type  of  attack.  A  bogus  foreign 
agent  can  be  configured  to  respond  to  the  mobile  node’s  agent  solicitation  with  its  agent 
advertisement,  resulting  in  IP  traffic  destined  for  the  mobile  node  to  be  tunneled  to  the 
bogus  foreign  agent’s  advertised  care-of  address,  as  depicted  in  Figure  50. 


2.  Agent  Advertisement 
with  Care-of  Address 

4b.  Registration  Reply 
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VI.  CONCLUSIONS 


The  Mobile  IP  protocol  specified  in  RFC  3344  [4]  defines  the  mechanisms  and 
protocol  behaviors  that  are  necessary  to  facilitate  the  seamless  flow  of  traffic  to  a  mobile 
host  that  roams  away  from  its  normal  home  network.  The  main  objective  of  this  research 
was  to  explore  how  this  capability  could  be  utilized  to  support  the  relatively  rapid 
roaming  of  an  IEEE  802.11  wirelessly  connected  host.  Specifically,  this  research  was 
focused  on  isolating  and  analyzing  the  constituent  components  underlying  the  Mobile  IP 
protocol  for  the  purpose  of  identifying  the  cost  drivers  that  may  be  improved  upon,  and 
recognizing  the  vulnerabilities  that  may  be  exploited  by  an  attacker  intent  on  denying  or 
delaying  proper  handoff  service. 

A  reference  architecture  was  devised  and  adopted  to  demonstrate  the  operations 
of  the  Mobile  IP  protocol  to  support  the  roaming  of  an  IEEE  802.1 1  wirelessly  connected 
host  in  a  controlled  environment.  Thereafter,  a  test  plan  was  formulated,  describing  the 
appropriate  test  cases  and  test  procedure  for  collecting  the  performance  statistics.  Having 
identified  the  potential  candidates  for  data  collection,  the  Mobile  IP  setup  was 
instrumented  to  facilitate  the  gathering  of  the  performance  statistics.  Data  collected  from 
the  different  sources  were  then  collated  and  analyzed  to  determine  the  performance 
statistics  corresponding  to  the  constituent  components  underlying  the  handoff  process. 

Based  on  the  results  that  were  obtained,  suggestions  were  made  to  fine-tune  the 
appropriate  parameters  to  possibly  improve  the  performance  of  the  different  cost  drivers. 
Using  the  traffic  requirements  for  different  types  of  applications  as  a  reference,  it  was 
concluded  that  Mobile  IP  should  have  no  problems  supporting  data  and  non-interactive 
video  traffic.  Further  enhancements  to  the  Mobile  IP  protocol  and  IEEE  802.11  standard 
will  be  required  in  order  to  support  real-time  traffic  such  as  voice  and  interactive  video 
applications. 

The  security  ramifications  for  the  Mobile  IP  setup  were  briefly  discussed.  A 
malicious  user  could  potentially  exploit  the  IEEE  802. 1 1  wireless  link  layer  mechanism, 
and  the  Mobile  IP  agent  discovery  process,  to  launch  denial-of-service,  man-in-the- 
middle,  and  traffic  redirection  types  of  attacks.  As  the  main  purpose  of  this  thesis 
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research  was  to  gather  the  performance  statistics  for  the  constituent  components 
underlying  the  Mobile  IP  handoff  process,  a  minimalist  configuration  was  adopted,  with 
minimal  security-related  services  enabled.  Thus,  this  is  a  potential  area  that  would  call  for 
further  research. 

A.  MAJOR  CHALLENGES 

The  journey  taken  to  reach  this  final  stage  of  the  thesis  research  was  not  a  smooth 
sailing  one.  One  of  the  major  challenges  encountered  was  to  be  able  to  work  within  the 
confines  of  existing  hardware  and  software  in  order  to  devise  an  appropriate  setup  that 
could  be  used  to  gather  the  performance  statistics.  More  often  than  not,  due  to  equipment 
age  and  peculiarities,  a  lot  of  time  and  effort  were  spent  troubleshooting  problems  that 
were  not  of  direct  relation  to  Mobile  IP.  One  would  frequently  need  to  think  out-of-the- 
box  and  come  up  with  innovative  solutions  in  order  to  work  within  the  existing 
boundaries. 

Despite  the  fact  that  vendor  documentation  were  made  available  for  the 
configuration  of  the  Mobile  IP  setup,  these  were  “component-based”  information  that 
offered  a  “silo”  view  of  how  Mobile  IP  operates.  Coupled  with  the  fact  that  there  were  no 
common  deployable  scenarios  that  utilized  both  the  mobile  client  software  with  the 
Mobile  IP  service-enabled  routers,  one  could  not  reference  existing  deployments  when 
problems  were  encountered.  As  a  result,  a  significant  amount  of  time  and  effort  were 
expended  on  trial-and-error  sessions  in  order  to  find  the  “correct  mix”  for  the  setup  to 
work. 

The  physical  location  where  the  Mobile  IP  setup  was  situated  also  posed  a 
challenge  to  the  data  collection  process.  As  the  IEEE  802.11  standard  operates  in  a 
frequency  band  that  is  shared  by  other  industrial,  scientific  and  medical  equipment  [25], 
its  operations  are  highly  susceptible  to  RF  interferences  from  its  neighboring  equipment. 
Having  the  setup  located  at  a  research  lab  with  a  significant  amount  of  equipment  and 
ongoing  activity  was  not  exactly  an  ideal  environment  for  the  collection  of  “baseline” 
performance  statistics.  The  workaround  was  to  collect  the  data  at  the  “silent  hours”  of  the 
day,  where  the  surrounding  environment  has  relatively  less  activity  taking  place. 


94 


The  instrumented  Mobile  IP  setup  relied  on  different  equipment  for  data 
collection,  which  had  led  to  the  need  for  collation  of  multiple  data  sources  in  order  to 
determine  the  performance  statistics  for  the  handoff  components.  The  process  of  manual 
data  collation  is  tedious  and  error-prone,  and  does  not  favor  scalability.  In  addition,  due 
to  the  different  time-precisions  that  are  used  by  the  various  data  collection  equipment,  the 
accuracy  of  the  collated  data  could  only  be  as  accurate  as  the  equipment  with  the  least 
time-precision.  Going  forward,  it  is  recommended  that  an  automated  tool  be  considered 
to  collect  and  collate  data  from  the  respective  authoritative  sources  to  address  accuracy 
and  scalability  concerns. 


B.  RECOMMENDATIONS  FOR  FUTURE  RESEARCH 

Working  within  the  confines  of  existing  hardware  and  software,  the  performance 
statistics  were  gathered  based  on  a  set  of  vendor-specific  products.  As  described  under 
the  Result  Analysis  section  of  the  previous  chapter,  the  main  cost  driver  for  the  Mobile  IP 
handoff  process  was  the  “Registration  and  Routing  Update”  component.  The  test  cases 
conducted  using  the  current  setup  were  based  on  a  “black-box”  approach,  with  one 
having  no  minute  information  on  the  exact  processing  that  took  place  when  the  home 
agent  decided  to  accept  a  registration  request.  Going  forward,  this  is  an  area  that  will  call 
for  further  research.  Specifically,  one  will  want  to  analyze  all  the  constituent  components 
underlying  the  registration  and  routing  update  process,  compare  that  against  the 
recommendations  given  in  RFC  3344  [4],  and  suggest  the  appropriate  enhancements  to 
improve  the  performance  of  the  “Registration  and  Routing  Update”  component. 
Additionally,  one  may  want  to  determine  the  relationship  between  the  handoff 
performance  and  the  router’s  internal  processing,  i.e.,  if  a  better  handoff  performance  will 
“stress”  the  router,  resulting  in  slower  processing  of  other  network  traffic,  and  vice  versa. 

As  it  was  the  intent  of  this  research  to  collect  the  “best-case”  performance 
statistics  from  a  relatively  “clean”  environment  using  a  minimalist  configuration,  it  will 
be  of  interest  to  explore  the  effect  of  network  load  on  the  router’s  processing  of  Mobile 
IP  related  traffic.  Consequently,  one  will  then  be  able  to  determine  if  the  router’s 
software  processing  is  sufficient  to  meet  the  performance  requirements  of  a  “real-world” 
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scenario,  and  recommend  possible  improvements  such  as  offloading  the  processing  to 
dedicated  hardware  component. 

The  unintentional  use  of  different  brands/models  of  access  points  has  introduced 
variability  in  the  results  obtained  for  the  link-layer  handoff  performance.  It  will  be  useful 
to  conduct  the  test  cases  using  a  variety  of  access  points  (with  the  option  to  configure  the 
scanning  and  control  parameters)  to  determine  the  “best-case”  link-layer  performance 
that  can  be  obtained,  and  recommend  the  corresponding  set  of  scanning  and  control 
parameters  that  will  provide  the  desired  link-layer  performance. 

A  decision  was  made  to  conduct  the  test  cases  based  on  “static”  data  transfer  over 
an  established  TCP  session  to  demonstrate  that  the  session  is  indeed  “maintained”  when  a 
mobile  node  roams  from  one  network  to  another.  To  facilitate  data  collection  and 
collation,  the  mobile  node  was  the  party  initiating  the  data  transfer  to  the  correspondent 
node  in  the  current  setup.  It  will  be  constructive  to  conduct  the  same  “static”  data  transfer 
over  TCP  with  the  correspondent  node  initiating  the  data  transfer  to  the  mobile  node,  to 
determine  if  there  will  be  any  variations  in  the  performance  statistics  associated  with  the 
handoff  process.  In  addition,  it  will  be  worthwhile  to  gather  the  performance  statistics  for 
test  cases  conducted  based  on  streaming  of  “non-interactive”  voice  and  video  over  a  UDP 
session,  to  facilitate  comparison  against  the  results  obtained  for  supporting  TCP  traffic. 

The  main  objective  of  this  research  was  to  conduct  a  performance  analysis  of  the 
Mobile  IP  protocol  to  support  the  relatively  rapid  roaming  of  an  IEEE  802.11  wirelessly 
connected  host.  As  a  result,  minimal  security-related  services  were  supported.  Knowing 
that  a  potentially  vulnerable  network  will  be  subjected  to  active  and  passive  attacks, 
ultimately  affecting  its  performance,  the  security  ramifications  would  justify  the  need  for 
further  research.  Specifically,  the  two  areas  that  would  need  to  be  addressed  would  be  the 
protection  of  the  IEEE  802.11  link  layer  handoff  mechanism,  and  the  protection  of  the 
Mobile  IP  registration  process  that  takes  place  via  a  foreign  agent.  Addressing  these  two 
areas  will  also  provide  farther  insights  on  how  the  performance  may  be  affected  through 
the  configuration  of  the  security-related  services. 

As  was  highlighted  in  the  previous  section,  the  current  mechanism  for  collecting 
and  collating  data  is  a  manual  process  that  is  tedious,  error-prone,  not  scaleable,  and  can 
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only  be  as  accurate  as  the  measuring  device  with  the  least  time-precision.  In  order  to 
support  the  identified  areas  for  future  research,  it  will  be  of  immediate  interest  and 
relevance  to  devise  an  automated  mechanism  to  collect  and  collate  the  data  from  the 
respective  authoritative  sources  to  address  accuracy  and  scalability  concerns. 

Last  but  not  least,  the  topic  on  mobility,  and  its  support  for  IP  applications, 
branches  out  into  many  facets;  ranging  from  micro-mobility  to  macro-mobility  [38], 
seamless  integration  with  cellular  networks,  support  for  mobile  ad-hoc  networking,  QoS 
and  traffic  engineering  considerations  for  supporting  real-time  traffic,  operational 
considerations  for  military  command  and  control,  varying  boundaries  and  the  security 
ramifications,  and  much  more.  The  scope  for  each  of  these  areas  would  justify  a  separate 
research  on  its  own.  Needless  to  say,  the  analysis  conducted  and  recommendations 
provided  as  a  result  of  this  thesis  research  have  only  addressed  a  tip  of  the  iceberg. 


97 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


98 


APPENDIX  A  -  CONFIGURATION  SETUP 


This  appendix  serves  to  document  the  configuration  details  of  the  respective 
components  that  were  used  to  setup  the  Mobile  IP  test  environment  as  illustrated  in 
Figure  39. 


A.  MOBILITY  AGENT 

A  mobility  agent  refers  to  a  home  agent  or  foreign  agent.  A  home  agent  and  two 
foreign  agents  were  configured  in  the  Mobile  IP  test  environment.  It  is  not  the  intent  of 
this  appendix  to  describe  the  step-by-step  procedure  for  router  configuration.  Rather,  this 
section  will  only  list  the  running  configuration  for  the  three  respective  routers.  Readers 
can  refer  to  [5]  and  [43]  for  a  more  thorough  treatment  on  how  to  configure  IP  mobility 
services  for  the  routers.  Similarly,  readers  can  also  refer  to  [44]  and  [45]  for  enabling  the 
DHCP  and  NTP  services  on  these  routers. 

1.  Home  Agent 

The  running  configuration  for  the  home  agent  is  shown  in  Figure  5 1 . 
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I 

!  Last  configuration  change  at  10:20:58  UTC  Mon  Nov  20  2006 
!  NVRAM  config  last  updated  at  12:46:18  UTC  Mon  Nov  20  2006 

i 

version  12.4 

service  timestamps  debug  datetime  msec 
service  timestamps  log  datetime  msec 
no  service  password-encryption 

i 

hostname  C262lXM_HomeAgent 

i 

boot- start-marker 
boot -end-marker 

i 

logging  buffered  4096  errors 

i 

no  aaa  new-model 

i 

resource  policy 

i 

no  network-clock-participate  slot  1 
no  network-clock-participate  wic  0 
ip  subnet-zero 

i 

i 

no  ip  dhcp  use  vrf  connected 

ip  dhcp  excluded-address  10.3.1.1  10.3.1.9 

ip  dhcp  excluded-address  10.3.1.251  10.3.1.255 

i 

ip  dhcp  pool  HomeNet  DHCP  Configuration 

network  10.3.1.0  255.255.255.0 
default-router  10.3.1.1 

i 

i 

ip  cef 

no  ip  ips  deny-action  ips-interf ace 

i 

i 

interface  LoopbackO 
ip  address  10.100.1.1  255.255.255.0 

i 

interface  FastEthernet0/0 
ip  address  10.1.1.2  255.255.255.0 
duplex  auto 
speed  auto 

i 
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interface  FastEthernetO/1 
ip  address  10.3.1.1  255.255.255.0 
duplex  auto 
speed  auto 

i 

interface  Ethernetl/0 
ip  address  10.5.1.1  255.255.255.0 
half-duplex 

i 

interface  Ethernetl/1 
no  ip  address 
shutdown 
half-duplex 

i 

interface  Ethernetl/2 
no  ip  address 
shutdown 
half-duplex 

i 

interface  Ethernetl/3 
no  ip  address 
shutdown 
half-duplex 

i 

router  mobile 

i 

ip  classless 

ip  route  10.2.1.0  255.255.255.0  10.1.1.1 
ip  route  10.4.1.0  255.255.255.0  10.1.1.3 

i 

i 

no  ip  http  server 

no  ip  http  secure-server 

ip  mobile  home-agent  Home  Agent 

ip  mobile  bindupdate  retry  1  Configuration 

ip  mobile  virtual-network  10.10.10.0  255.255.255.0 
ip  mobile  host  nai  mn@nps  static-address  10.10.10.1  virtual- 
network  10.10.10.0  255.255.255.0 

ip  mobile  secure  host  nai  mn@nps  spi  1234  key  hex 
12345678123456781234567812345678  algorithm  hmac-md5 
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agents. 


I 

no  cdp  run 

i 

i 

i 

control -plane 

i 

i 

line  con  0 
session-timeout  180 
logging  synchronous 
line  aux  0 
line  vty  0  4 
login 

i 

ntp  clock-period  17179470  NTP  Configuration 

ntp  server  10.1.1.1  key  1234  source  FastEthernetO/O 

i 

end 


Figure  5 1 .  Home  Agent’s  Running  Configuration. 

2.  Foreign  Agent 

Figure  52  and  Figure  53  show  the  running  configuration  for  the  two  foreign 
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I 

!  Last  configuration  change  at  10:40:03  UTC  Mon  Nov  20  2006 
!  NVRAM  config  last  updated  at  12:46:51  UTC  Mon  Nov  20  2006 

i 

version  12.4 

service  timestamps  debug  datetime  msec 
service  timestamps  log  datetime  msec 
no  service  password-encryption 

i 

hostname  C265lXM_ForeignAgentl 

i 

boot- start-marker 
boot -end-marker 

i 

i 

no  aaa  new-model 

i 

resource  policy 

i 

no  network-clock-participate  slot  1 
no  network-clock-participate  wic  0 
ip  subnet-zero 

i 

i 

no  ip  dhcp  use  vrf  connected 

i 

i 

ip  cef 

no  ip  ips  deny-action  ips-interf ace 

i 

i 

interface  LoopbackO 
no  ip  address 

i 

interface  FastEthernet0/0 
ip  address  10.1.1.1  255.255.255.0 
duplex  auto 
speed  auto 

i 

interface  Serial0/0 
no  ip  address 
shutdown 

i 
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interface  FastEthernetO/1 
ip  address  10.2.1.1  255.255.255.0 


ip  mobile  foreign-service 
ip  irdp 

ip  irdp  maxadvertinterval  4 
ip  irdp  minadvertinterval  3 
ip  irdp  holdtime  9 
speed  auto 
half-duplex 

i 

Foreign  Agent 
Configuration 

interface  Serial0/1 
no  ip  address 
shutdown 

i 

interface  SerialO/2 
no  ip  address 
shutdown 

i 

interface  SerialO/3 
no  ip  address 
shutdown 

i 

router  mobile 

i 

ip  classless 

ip  route  10.5.1.0  255.255.255.0 
ip  route  10.100.1.0  255.255.255. 

i 

10.1.1.2 

.0  10.1.1.2 

no  ip  http  server 

no  ip  http  secure-server 

ip  mobile  foreign-agent  care-of 

i 

FastEthernetO/1 

no  cdp  run 

i 

control-plane 

i 

dial-peer  cor  custom 

i 

line  con  0 

session-timeout  180 
logging  synchronous 
line  aux  0 
line  vty  0  4 
login 

i 

ntp  authentication-key  1234  md5 
ntp  trusted-key  1234 
ntp  source  FastEthernet0/0 
ntp  master  6 

i 

062E2E1E7847041C  7 

NTP  Configuration 

end 

Figure  52.  Foreign  Agent  1  ’s  Running  Configuration. 
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!  Last  configuration  change  at  10:39:18  UTC  Mon  Nov  20  2006 
!  NVRAM  config  last  updated  at  12:47:26  UTC  Mon  Nov  20  2006 

! 

version  12.4 

service  timestamps  debug  date time  msec 
service  timestamps  log  date time  msec 
no  service  password-encryption 

I 

hostname  C2651XM_ForeignAgent2 

! 

boot-start-marker 
boot -end-marker 

I 

! 

no  aaa  new-model 

i 

resource  policy 

i 

no  network-clock-participate  slot  1 
no  network-clock-participate  wic  0 
ip  subnet-zero 

i 

i 

no  ip  dhcp  use  vrf  connected 

! 

I 

ip  cef 

no  ip  ips  deny-action  ips-interf ace 

! 

! 

interface  FastEthernet0/0 
ip  address  10.1.1.3  255.255.255.0 
duplex  auto 
speed  auto 

! 

interface  Serial0/0 
no  ip  address 
shutdown 
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interface  FastEthernetO/1 
ip  address  10.4.1.1  255.255.255.0 
ip  mobile  foreign-service 


ip  irdp 

ip  irdp  maxadvertinterval  4 
ip  irdp  minadvertinterval  3 
ip  irdp  holdtime  9 
speed  auto 
half-duplex 

i 

Foreign  Agent 
Configuration 

interface  Serial0/1 
no  ip  address 
shutdown 

i 

interface  SerialO/2 
no  ip  address 
shutdown 

i 

interface  SerialO/3 
no  ip  address 
shutdown 

i 

router  mobile 

i 

ip  classless 

ip  route  10.5.1.0  255.255.255.0 
ip  route  10.100.1.0  255.255.255. 

i 

10.1.1.2 

.0  10.1.1.2 

i 

no  ip  http  server 

no  ip  http  secure-server 

ip  mobile  foreign-agent  care-of 

i 

FastEthernetO/1 

no  cdp  run 

i 

control -plane 

i 

line  con  0 

session-timeout  180 
logging  synchronous 
line  aux  0 
line  vty  0  4 
login 

i 

ntp  clock-period  17207990 

NTP  Configuration 

ntp  server  10.1.1.1  key  1234  source  FastEthernetO/O 

i 

end 


Figure  53.  Foreign  Agent  2’s  Running  Configuration. 
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B.  ACCESS  POINT 

Two  ESSs,  corresponding  to  the  two  foreign  networks,  were  configured  for  the 
Mobile  IP  setup.  As  described  in  Chapter  4,  each  of  the  ESSs  has  a  single  BSS,  which  is 
served  by  an  access  point.  Figure  54  and  Figure  55  list  the  configuration  for  access  point 
1  and  access  point  2  respectively.  Readers  can  refer  to  [46]  for  the  detailed  user  guide  for 
access  point  1,  and  [47]  for  the  user  guide  for  access  point  2. 


Setup 


This  screen  contains  all  of  the  AP's  basic  setup  functions.  Most  users 
will  be  able  to  use  the  AP's  default  settings  without  making  any 
changes.  If  you  require  help  during  configuration,  please  see  the  user 
guide. 


Firmware  Version: 


LAN  IP  Address: 


1.1 

|l inksys  WAP1 1 

(MAC  Address:  00-06-25-54-B  i-OF  ) 

Obtain  an  IP  Address  Automatically 
(*  Specify  an  IP  Address  |l0  |  .  \2 

Subnet  Mask:  i| 2 5 5  ,  1 2 5 5 

Gateway:  |l  0 


■  F 


(MAC  Address:  00-06-25-54-DE-CC  ) 

SSID:  [cs4910-L3 

Channel:  IT3  (Domain:  USA  ) 

WEP:  C  Mandatory  Disable 


WEP  Key  Setting 


Access  Point 

C  Access  Point  Client  Remote  AP  MAC  Address  |000000000000 

C  wireless  Bridge  Remote  Bridge  MAC  Address  [ 

C  Wireless  Bridge  -  Point  to  Multipoint 

When  set  to  "Access  Point  Client",  "Wireless  Bridge"  or  "Wireless  Bridge  - 
Point  to  Multipoint"  mode,  the  device  will  only  communicate  with  another 
WAP  11  ver.  2.2  or  WAP  11. 


Backup/Restore 
Setting  : 


Backup 


Restore 


Click  "Backup"  to  store  Access  Point  configuration  on  your  local  PC. 

Click  "Restore"  to  restore  Access  Point  configuration  from  your  local  PC, 


Apply  |  Cancel  |  Help  | 
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HI  Unksys  ■ 


WIRELESS 


Beacon  Interval: 

RTS  Threshold: 

Fragmentation 

Threshold: 

□TIM  Interval: 


Basic  Rates: 


Transmission  Rates: 


Preamble  Type: 


Authentication  Type: 


Antenna  Selection: 


SSID  Broadcast: 


The  advance  Wireless  Setting  includes  Beacon  Interval,  RTS  Threshold, 
Fragmentation,  DTIM  interval,  Rates,  Authentication  Type  etc. 


[Too  (msec,  range:  1- 1000,  default:  100) 

[2432  (range:  256-2432,  default:  2432) 

[2346  (range:  256-2346,  default: 2346,  even  number  only) 
P  (range:  1-65535,  default: 3) 

F  l-2(Mbps)  C  1-2-5. 5-ll(Mbps) 

C  l-2(Mbps)  <*  1-2-5. 5-ll(Mbps) 

T"  Short  Preamble  f*  Long  Preamble 
C  Open  System  r  Shared  Key  (*  Both 
r  Left  Antenna  r  Right  Antenna  Diversity  Antenna 
f*  Enable  C  Disable 


Apply  |  Cancel  |  Help  | 


H  I  IMKSVfi  1 


STATUS 


This  screen  displays  the  AP's  current  status  and  settings.  This 
information  is  read-only, 


(MAC  Address:  00-06-25-54-B1-0F  ) 


CS4910-L3 
Disable 
S 

29S74 

2 

3S 

0 

In  wireless  transmission,  some  dropped  packets  occurence  is  normal. 


Figure  54.  Access  Point  l’s  Configuration. 
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D 6LL 

Dell  True  Mobile 

1170  Wirel 

less  Base  Station 

DEVICE 

DEVICE  SETUP 

ADVANCED 

SYSTEM 

TOOLS  MELP 

INFORMATION 

STATUS  WIZARD 

SETTINGS 

Main  menu 


WIRELESS  SETTINGS 


ESSID 

Channel 

Key  Format 


jcs491 0-L3 

Fn 

|  Hexadecimal  Digits  T| 


(*  No  Encryption 


<~  40(64)  Bit 

Key  1 

¥~ 

FH 

F” 

F” 

F^ 

Default  Key: 

Key  2 

IT 

F“ 

FZ 

F“ 

Is 

ra 

Key  3 

IT 

r 

Is 

Is 

FT 

Key  4 

n 

Is 

1° 

Is 

Is 

c  128  Bit 

F~ 

F~ 

F" 

F" 

F~ 

F~ 

F~ 

F~ 

1° 

1° 

1° 

F" 

1° 

<  [mext  > 


D^Li 

0*11  TrutMobil* 

1170  Wireless  Base  Station 

DEVICE 

DEVICE  SETUP 

ADVANCED  SYSTEM  Mpr|  - 
SETTINGS  TOOLS  ncLF 

INFORMATION 

STATUS  WIZARD 

Main  menu 


DEVICE  IP  SETTINGS 


The  device  IP  address  and  subnet  mask  settings 


IP  Address: 

|io 

FZ 

l-D__ 

IT 

IP  Subnet  Mask: 

|255 

.  i|255 

] .  I255 

IT 

D*LL 

Dell  TrueMablle 

1170  Wireless  Base  Station 

DEVICE 

DEVICE  SETUP 

ADVANCED  SYSTEM  umt  m 
SETTINGS  TOOLS  ncLK 

INFORMATION 

STATUS  WIZARD 

Main  menu 


DEVICE  INFORMATION 


Device  Name:  Wireless 
IP  Address:  10  4  12 

Private  LAN  Mac  Address:  00:02:b3:94:39:62 
Public  WAN  (Cable/DSL)  Mac  Address:  00:02 :b3:94:39:63 
Firmware  Version:  V4.73  (2002/04/12) 
Boot  Block  Version:  VI  00 
Radio  Firmware  Version:  VS  30 


Figure  55.  Access  Point  2’s  Configuration. 
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C.  MOBILE  NODE 

The  Cisco  Mobile  Client  version  2.0.14  software  was  used  to  enable  the  station  to 
function  as  a  mobile  node.  Figure  56  briefly  describes  the  steps  that  are  required  to 
configure  the  mobile  node,  and  Figure  57  illustrates  the  status  of  the  Cisco  Mobile  Client 
when  the  mobile  node  roams  from  one  foreign  network  to  another  foreign  network. 
Readers  can  refer  to  [34]  for  a  more  thorough  treatment  on  how  to  configure  the  Cisco 
Mobile  Client  software. 


1 .  Right  click  on  Cisco  Mobile  Client 
&  Select  “Configure  a  Profile...” 


View  log... 

Dial 

Authentication  profiles 

Cisco  VPN 

Adapters... 

Profiles... 


Configure  a  Profile... 


Change  Password... 
Dial-up  Configuration. . . 
Static  IP... 

Signal  strength... 

Enable 

Disable 

Exit 

■  Muuress  ■  T  -g 


2.  Double  click  on  default  template  under  “Profile  Name”  to  configure 
a  profile. 


3.  The  “Profile  Configuration  Dialog” 
appears.  Fill  in  all  the  fields  with  the 
values  displayed. 


no 


Profile  Configuration  Dialog 


Profile  Name/ID:  |  mn@nps 

Mobility  j  Security  |  Connection  | 
Home  Address  and  NAI: 


C  Static  Address:  |  10  .  10  .  10 
(*  Dynamic  by  NAI:  |  mn@nps 


Mask:  |  255  .  255  .  255  .  0 

Default  Gateway:  |  10 


10  .  10 


Home  Advanced 


DNS  and  WINS 


Home  Agent: 


Static  (External)  HA:  |  10  •  100  .  1  "  1  Security  Association  | 

r  Static  Internal  HA:  |  10  •  100  i 


AAA  Authentication: 


Include  AAA  Authentication: 


Secu  -ity  Association 


HA  Authentication  Settings: 


SPI:  1 1234 


(in  Hex) 


Hex 


Key  Type: 

Key:  1 1  23456781 23456781  23456781 2345678 


16 


Algorithm:  HMAC-MD5 


M 


Cancel 


OK 


DNS  and  WINS  Dialog 


DNS  |  WINS  | 


DNS  Server  List: 


—  Modify 


DNS  Suffix  List: 


—  Modify 


4.  Click  on  the  “DNS  and  WINS”  button  in  the  “Profile 
Configuration  Dialog”.  Fill  in  all  the  fields  with  the 
values  displayed. 


MIP  Advanced  Settings: 


Solicitation  Address:  |  224  .  0  "  0 

Force  Reverse  Tunneling:  (Don't 

EjPassThru  Mode 
0  j”  Broadcast 
EjrjBroadcast  on  PPP 


6.  Click  on  the  “Security  Association”  button  in  the  “Profile  Configuration 
Dialog”.  The  security  association  settings  configured  for  the  mobile  node 
must  match  those  that  are  configured  at  the  home  agent  for  this  mobile 
node. 


Initial  Re-registration  Time:  |~4 
Re-registration  Minimal  Time:  [30 
Re-registration  Threshold:  |~90 
Co-located  Registration  Time:  |  600 
Wait  Co-located  Time:  |~2 


[s] 

[s] 

[%] 

[s] 

[s] 


5.  Click  on  the  “MIP  Advanced”  button  in  the  “Profile 
Configuration  Dialog”.  Use  the  default  settings  as  displayed. 


Figure  56.  Mobile  Node’s  Configuration. 
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1 .  Double  click  on  Cisco  Mobile  Client  to  get 
“Mobile  Client  Properties”  dialog  box. 
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Mobile  Client  Properties 


X] 


About 


Config  j 


Status 

Using  Adapter 
State 

Current  Agent 
Care-oF  Address 
IPSec 

Mode 


Cisco  Systems  3j£i  Series  FCMCI 

(^Registeredaway^) 


Configuration 
Home  Agent  Public 

Home  Agent  Private 
IP  Address 


10.4.1.1 
10.4.1.1 
Not  connected 

Normal 


10.100.1.1 

10.100.1.1 

10.10,10.1 


Close 


/ 


5a.  The  mobile  node  roams  to 
foreign  network  2.  The  dialog 
box  shows  the  mobile  node 
has  successfully  registered 
via  foreign  agent  2  and  is 
“registered  away”. 


5b.  Note  status  of 
Cisco  Mobile  Client. 


Figure  57.  Cisco  Mobile  Client  in  Operation. 
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APPENDIX  B  -  TEST  RESULTS 


This  appendix  details  the  collated  results  for  the  individual  test  cases  that  were 
used  to  derive  the  summary  statistics  shown  in  Figure  44  and  Figure  45. 


A.  ROAMING  FROM  FOREIGN  NETWORK  1  TO  FOREIGN  NETWORK  2 

The  collated  results  for  the  individual  test  cases  conducted  for  the  scenario  when 
the  mobile  node  roams  from  foreign  network  1  to  foreign  network  2  are  detailed  in 
Tables  18,  19  and  20. 


Data  Set 

Move  Detection 

Link  Layer  Handoff  Agent  Discovery 

Registration  & 

Routing  Upate 

Total 

1 

2.948 

0.049 

3.032 

6.029 

5 

0.404 

0.101 

3.033 

3.539 

7 

0.088 

0.066 

3.033 

3.186 

9 

0.394 

0.089 

3.033 

3.516 

11 

0.456 

22.196 

3.037 

25.690 

13 

9.042 

2.133 

3.032 

14.207 

17 

1.027 

5.504 

3.033 

9.565 

21 

2.254 

0.113 

3.033 

5.400 

23 

23.331 

0.020 

3.033 

26.385 

27 

0.080 

0.049 

3.033 

3.162 

31 

1.334 

0.048 

3.033 

4.415 

35 

1.171 

0.043 

3.037 

4.251 

37 

0.171 

0.072 

3.037 

3.280 

39 

1.699 

0.065 

3.033 

4.797 

41 

1.895 

0.087 

3.033 

5.015 

43 

0.672 

0.119 

3.041 

3.832 

45 

2.487 

0.020 

3.033 

5.540 

47 

0.096 

0.078 

3.041 

3.214 

49 

4.959 

0.022 

3.033 

8.014 

51 

0.667 

0.064 

3.037 

3.768 

53 

0.019 

0.103 

3.033 

3.155 

57 

14.496 

0.010 

3.037 

17.543 

59 

6.577 

1.006 

3.032 

10.615 

63 

0.887 

0.061 

3.033 

3.981 

65 

1.610 

0.116 

3.033 

4.759 

67 

1.224 

0.047 

3.033 

4.304 

69 

0.307 

0.061 

3.037 

3.404 

P51 

0.121 

0.066 

3.033 

3.220 

P23 

0.950 

0.047 

3.033 

4.030 

P19 

0.945 

3.455 

3.033 

7.433 

P11 

0.087 

0.114 

3.033 

3.235 

Total 

82.397 

36.025 

94.060 

212.483 

Average 

2.658 

1.162 

3.034 

6.854 

Table  18.  Detailed  Test  Results  for  Mobile  IP  Handoff  Components  (in  Seconds)  - 
Roaming  from  Foreign  Network  1  to  Foreign  Network  2. 
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Data  Set 

Scanning 

Link  Layer  Handoff 
Authentication 

Association 

Total 

1 

0.057 

0.204 

2.687 

2.948 

5 

0.370 

0.032 

0.002 

0.404 

7 

0.078 

0.002 

0.008 

0.088 

9 

0.007 

0.379 

0.008 

0.394 

11 

0.022 

0.399 

0.036 

0.456 

13 

0.530 

8.462 

0.050 

9.042 

17 

0.020 

0.998 

0.009 

1.027 

21 

1.770 

0.465 

0.020 

2.254 

23 

23.218 

0.104 

0.009 

23.331 

27 

0.073 

0.005 

0.002 

0.080 

31 

0.610 

0.721 

0.003 

1.334 

35 

0.796 

0.372 

0.003 

1.171 

37 

0.162 

0.005 

0.004 

0.171 

39 

0.008 

1.683 

0.009 

1.699 

41 

0.522 

1.366 

0.007 

1.895 

43 

0.099 

0.570 

0.003 

0.672 

45 

1.664 

0.818 

0.006 

2.487 

47 

0.086 

0.007 

0.003 

0.096 

49 

4.611 

0.340 

0.007 

4.959 

51 

0.249 

0.416 

0.002 

0.667 

53 

0.008 

0.006 

0.005 

0.019 

57 

2.727 

11.751 

0.018 

14.496 

59 

3.578 

2.981 

0.018 

6.577 

63 

0.221 

0.661 

0.005 

0.887 

65 

0.489 

1.118 

0.004 

1.610 

67 

0.644 

0.576 

0.003 

1.224 

69 

0.091 

0.213 

0.002 

0.307 

P51 

0.114 

0.006 

0.001 

0.121 

P23 

0.226 

0.721 

0.003 

0.950 

P19 

0.492 

0.439 

0.015 

0.945 

P11 

0.061 

0.004 

0.022 

0.087 

Total 

43.600 

35.822 

2.975 

82.397 

Average 

1.406 

1.156 

0.096 

2.658 

Table  19.  Detailed  Test  Results  for  Link  Layer  Handoff  Components  (in  Seconds)  - 
Roaming  from  Foreign  Network  1  to  Foreign  Network  2. 
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Data  Set  Registration  &  Routing  Upate  Total 


FA'S 

Process¬ 
ing  of 
RRQ 

FA -HA 

Trans¬ 
mission 
Delay  (for 
RRQ) 

Authenti¬ 

cation 

Update 
Mobility 
Binding  & 
Create 
Tunnel 

Delete  Old 
Tunnel  & 
Update 
Route 

HA 

Accepts 
RRQ  & 

Sends 

RRP  to  FA 

HA -FA 

Trans¬ 
mission 
Delay  (for 
RRP) 

FA's 

Process¬ 
ing  of  RRP 

1 

0.004 

0.005 

0.004 

0.004 

0.008 

3.000 

0.003 

0.004 

3.032 

5 

0.000 

0.005 

0.004 

0.008 

0.004 

3.004 

0.004 

0.004 

3.033 

7 

0.004 

0.003 

0.004 

0.004 

0.008 

3.000 

0.006 

0.004 

3.033 

9 

0.004 

0.006 

0.004 

0.004 

0.004 

3.003 

0.008 

0.000 

3.033 

11 

0.004 

0.003 

0.004 

0.008 

0.004 

3.004 

0.005 

0.005 

3.037 

13 

0.000 

0.004 

0.004 

0.008 

0.004 

3.004 

0.004 

0.004 

3.032 

17 

0.004 

0.000 

0.008 

0.004 

0.004 

3.004 

0.005 

0.004 

3.033 

21 

0.004 

0.004 

0.004 

0.004 

0.008 

3.000 

0.005 

0.004 

3.033 

23 

0.004 

0.005 

0.004 

0.004 

0.004 

3.004 

0.004 

0.004 

3.033 

27 

0.004 

0.002 

0.004 

0.008 

0.004 

3.004 

0.007 

0.000 

3.033 

31 

0.000 

0.004 

0.004 

0.008 

0.004 

3.004 

0.005 

0.004 

3.033 

35 

0.004 

0.003 

0.004 

0.004 

0.008 

3.004 

0.006 

0.004 

3.037 

37 

0.004 

0.004 

0.004 

0.008 

0.004 

3.004 

0.005 

0.004 

3.037 

39 

0.000 

0.007 

0.004 

0.004 

0.008 

3.000 

0.006 

0.004 

3.033 

41 

0.004 

0.005 

0.004 

0.004 

0.004 

3.004 

0.004 

0.004 

3.033 

43 

0.004 

0.002 

0.008 

0.004 

0.004 

3.008 

0.007 

0.004 

3.041 

45 

0.004 

0.005 

0.004 

0.004 

0.008 

3.000 

0.004 

0.004 

3.033 

47 

0.000 

0.017 

0.004 

0.004 

0.004 

3.004 

0.004 

0.004 

3.041 

49 

0.000 

0.005 

0.004 

0.008 

0.004 

3.004 

0.004 

0.004 

3.033 

51 

0.004 

0.004 

0.004 

0.008 

0.004 

3.004 

0.005 

0.004 

3.037 

53 

0.000 

0.007 

0.004 

0.004 

0.004 

3.004 

0.006 

0.004 

3.033 

57 

0.004 

0.004 

0.004 

0.008 

0.004 

3.004 

0.005 

0.004 

3.037 

59 

0.000 

0.007 

0.004 

0.004 

0.004 

3.004 

0.005 

0.004 

3.032 

63 

0.004 

0.002 

0.004 

0.008 

0.004 

3.004 

0.007 

0.000 

3.033 

65 

0.004 

0.006 

0.004 

0.004 

0.004 

3.004 

0.007 

0.000 

3.033 

67 

0.004 

0.004 

0.004 

0.004 

0.004 

3.004 

0.005 

0.004 

3.033 

69 

0.004 

0.004 

0.004 

0.008 

0.004 

3.004 

0.005 

0.004 

3.037 

P51 

0.004 

0.004 

0.004 

0.004 

0.008 

3.000 

0.005 

0.004 

3.033 

P23 

0.005 

0.005 

0.004 

0.004 

0.008 

3.000 

0.003 

0.004 

3.033 

P19 

0.004 

0.005 

0.004 

0.004 

0.004 

3.004 

0.004 

0.004 

3.033 

P11 

0.004 

0.002 

0.004 

0.008 

0.004 

3.004 

0.007 

0.000 

3.033 

Total 

0.093 

0.143 

0.132 

0.172 

0.156 

93.099 

0.160 

0.105 

94.060 

Average 

0.003 

0.005 

0.004 

0.006 

0.005 

3.003 

0.005 

0.003 

3.034 

Table  20.  Detailed  Test  Results  for  Registration  and  Routing  Update  Components13  (in 
Seconds)  -  Roaming  from  Foreign  Network  1  to  Foreign  Network  2. 


13  Legend:  FA  refers  to  Foreign  Agent. 
Request.  RRP  refers  to  Registration  Reply. 


HA  refers  to  Home  Agent. 


RRQ 


refers  to  Registration 
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B.  ROAMING  FROM  FOREIGN  NETWORK  2  TO  FOREIGN  NETWORK  1 

The  collated  results  for  the  individual  test  cases  conducted  for  the  scenario  when 
the  mobile  node  roams  from  foreign  network  2  to  foreign  network  1  are  detailed  in 
Tables  21,  22  and  23. 


Data  Set 

Move  Detection 

Link  Layer  Handoff  Agent  Discovery 

Registration  & 

Routing  Upate 

Total 

2 

0.402 

0.106 

3.037 

3.544 

4 

0.880 

0.075 

3.033 

3.988 

6 

0.056 

0.099 

3.033 

3.188 

8 

0.067 

0.054 

3.033 

3.154 

12 

0.905 

2.847 

3.033 

6.785 

14 

0.015 

0.087 

3.037 

3.139 

16 

1.654 

0.117 

3.033 

4.804 

18 

0.271 

0.042 

3.033 

3.346 

22 

1.809 

0.474 

3.033 

5.316 

26 

0.889 

0.079 

3.037 

4.005 

28 

11.032 

0.017 

3.037 

14.086 

30 

0.069 

0.056 

3.037 

3.162 

32 

4.759 

0.664 

3.033 

8.456 

34 

1.115 

0.063 

3.033 

4.211 

36 

0.072 

0.096 

3.033 

3.201 

38 

0.162 

0.097 

3.033 

3.292 

40 

0.063 

0.027 

3.033 

3.124 

42 

0.070 

0.040 

3.037 

3.147 

44 

0.679 

0.105 

3.033 

3.817 

46 

13.494 

0.024 

3.033 

16.552 

48 

0.083 

0.090 

3.033 

3.206 

50 

0.690 

1.050 

3.037 

4.776 

52 

0.479 

0.075 

3.037 

3.591 

54 

0.209 

0.047 

3.033 

3.289 

56 

0.745 

0.096 

3.033 

3.873 

58 

0.136 

0.060 

3.033 

3.230 

60 

0.066 

0.078 

3.033 

3.176 

62 

0.755 

0.044 

3.033 

3.832 

64 

0.068 

0.043 

3.033 

3.144 

66 

0.126 

0.047 

3.033 

3.206 

68 

1.162 

0.052 

3.033 

4.247 

70 

0.191 

0.052 

3.037 

3.280 

Total 

43.169 

6.905 

97.092 

147.166 

Average 

1.349 

0.216 

3.034 

4.599 

Table  21.  Detailed  Test  Results  for  Mobile  IP  Handoff  Components  (in  Seconds)  - 
Roaming  from  Foreign  Network  2  to  Foreign  Network  1. 
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Data  Set 

Scanning 

Link  Layer  Handoff 
Authentication 

Association 

Total 

2 

0.006 

0.392 

0.004 

0.402 

4 

0.050 

0.827 

0.003 

0.880 

6 

0.049 

0.004 

0.003 

0.056 

8 

0.060 

0.004 

0.003 

0.067 

12 

0.214 

0.682 

0.009 

0.905 

14 

0.005 

0.004 

0.006 

0.015 

16 

0.426 

1.128 

0.100 

1.654 

18 

0.141 

0.126 

0.003 

0.271 

22 

1.795 

0.011 

0.003 

1.809 

26 

0.296 

0.590 

0.003 

0.889 

28 

0.005 

11.015 

0.011 

11.032 

30 

0.062 

0.005 

0.003 

0.069 

32 

0.007 

4.750 

0.003 

4.759 

34 

0.005 

1.108 

0.003 

1.115 

36 

0.064 

0.005 

0.003 

0.072 

38 

0.070 

0.090 

0.003 

0.162 

40 

0.056 

0.004 

0.003 

0.063 

42 

0.062 

0.005 

0.003 

0.070 

44 

0.320 

0.356 

0.003 

0.679 

46 

3.091 

10.401 

0.003 

13.494 

48 

0.073 

0.004 

0.005 

0.083 

50 

0.023 

0.662 

0.005 

0.690 

52 

0.012 

0.464 

0.003 

0.479 

54 

0.201 

0.005 

0.003 

0.209 

56 

0.131 

0.611 

0.003 

0.745 

58 

0.129 

0.005 

0.003 

0.136 

60 

0.058 

0.004 

0.003 

0.066 

62 

0.095 

0.658 

0.003 

0.755 

64 

0.060 

0.005 

0.003 

0.068 

66 

0.115 

0.007 

0.003 

0.126 

68 

0.260 

0.846 

0.055 

1.162 

70 

0.060 

0.128 

0.003 

0.191 

Total 

8.001 

34.906 

0.262 

43.169 

Average 

0.250 

1.091 

0.008 

1.349 

Table  22.  Detailed  Test  Results  for  Link  Layer  Handoff  Components  (in  Seconds)  - 
Roaming  from  Foreign  Network  2  to  Foreign  Network  1. 
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Registration  &  Routing  Upate 

Total 

FA'S 

FA -HA 

Authenti-  Update 

Delete  Old 

HA 

HA -FA 

FA's 

Process¬ 

Trans¬ 

cation  Mobility 

Tunnel  & 

Accepts 

Trans¬ 

Process¬ 

ing  of 

mission 

Binding  & 

Update 

RRQ  & 

mission 

ing  of  RRP 

RRQ 

Delay  (for 
RRQ) 

Create 

Tunnel 

Route 

Sends 

RRP  to  FA 

Delay  (for 
RRP) 

2 

0.004 

0.003 

0.004 

0.008 

0.004 

3.004 

0.006 

0.004 

3.037 

4 

0.005 

0.006 

0.004 

0.004 

0.004 

3.004 

0.006 

0.000 

3.033 

6 

0.000 

0.007 

0.004 

0.004 

0.008 

3.000 

0.006 

0.004 

3.033 

8 

0.004 

0.004 

0.004 

0.004 

0.008 

3.000 

0.005 

0.004 

3.033 

12 

0.000 

0.006 

0.004 

0.004 

0.008 

3.004 

0.007 

0.000 

3.033 

14 

0.004 

0.004 

0.004 

0.008 

0.004 

3.004 

0.005 

0.004 

3.037 

16 

0.004 

0.005 

0.004 

0.004 

0.008 

3.000 

0.004 

0.004 

3.033 

18 

0.000 

0.006 

0.004 

0.008 

0.004 

3.004 

0.003 

0.004 

3.033 

22 

0.004 

0.006 

0.004 

0.004 

0.004 

3.003 

0.004 

0.004 

3.033 

26 

0.004 

0.003 

0.004 

0.008 

0.004 

3.004 

0.006 

0.004 

3.037 

28 

0.004 

0.003 

0.004 

0.008 

0.004 

3.004 

0.006 

0.004 

3.037 

30 

0.004 

0.004 

0.004 

0.004 

0.008 

3.004 

0.005 

0.004 

3.037 

32 

0.004 

0.005 

0.004 

0.004 

0.008 

3.000 

0.004 

0.004 

3.033 

34 

0.004 

0.002 

0.004 

0.008 

0.004 

3.004 

0.003 

0.004 

3.033 

36 

0.004 

0.002 

0.004 

0.008 

0.004 

3.003 

0.004 

0.004 

3.033 

38 

0.000 

0.005 

0.004 

0.008 

0.004 

3.004 

0.004 

0.004 

3.033 

40 

0.000 

0.008 

0.004 

0.004 

0.004 

3.003 

0.006 

0.004 

3.033 

42 

0.004 

0.004 

0.004 

0.008 

0.004 

3.004 

0.005 

0.004 

3.037 

44 

0.004 

0.001 

0.008 

0.004 

0.004 

3.004 

0.004 

0.004 

3.033 

46 

0.004 

0.006 

0.004 

0.004 

0.008 

3.000 

0.007 

0.000 

3.033 

48 

0.000 

0.005 

0.004 

0.004 

0.008 

3.004 

0.004 

0.004 

3.033 

50 

0.004 

0.005 

0.004 

0.004 

0.008 

3.004 

0.004 

0.004 

3.037 

52 

0.004 

0.005 

0.004 

0.008 

0.004 

3.004 

0.004 

0.004 

3.037 

54 

0.004 

0.003 

0.004 

0.008 

0.004 

3.003 

0.007 

0.000 

3.033 

56 

0.004 

0.005 

0.004 

0.004 

0.008 

3.000 

0.004 

0.004 

3.033 

58 

0.000 

0.006 

0.004 

0.008 

0.004 

3.004 

0.003 

0.004 

3.033 

60 

0.000 

0.007 

0.004 

0.004 

0.008 

3.000 

0.006 

0.004 

3.033 

62 

0.000 

0.008 

0.004 

0.004 

0.004 

3.004 

0.005 

0.004 

3.033 

64 

0.000 

0.007 

0.004 

0.004 

0.004 

3.004 

0.006 

0.004 

3.033 

66 

0.004 

0.004 

0.004 

0.004 

0.008 

3.000 

0.005 

0.004 

3.033 

68 

0.004 

0.004 

0.004 

0.004 

0.004 

3.004 

0.005 

0.004 

3.033 

70 

0.004 

0.003 

0.004 

0.008 

0.004 

3.004 

0.006 

0.004 

3.037 

Total 

0.089 

0.152 

0.132 

0.180 

0.176 

96.092 

0.159 

0.112 

97.092 

Average 

0.003 

0.005 

0.004 

0.006 

0.005 

3.003 

0.005 

0.003 

3.034 

Table  23.  Detailed  Test  Results  for  Registration  and  Routing  Update  Components14  (in 
Seconds)  -  Roaming  from  Foreign  Network  2  to  Foreign  Network  1. 


14  Legend:  FA  refers  to  Foreign  Agent. 
Request.  RRP  refers  to  Registration  Reply. 


HA  refers  to  Home  Agent. 


RRQ 


refers  to  Registration 
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